cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject [RT] Changing Abstraction
Date Tue, 13 Dec 2005 15:14:51 GMT
IMO, abstraction is not bad, however the wrong abstraction is.  Using 
the right abstraction can make using a library or tool much easier to 
grasp and use.

Now, I'm sure you are sick of Ruby and Rails, but I'd like to share a 
little about how the user interacts with the environment there.  It 
might help us come up with a decent abstraction here.  First, there is a 
huge difference between the ease of using Maps in Java and Ruby, so they 
are more prevalent in Ruby apps.  Here is what it looks like to get your 
parameters in Ruby:

val = @request['name']

What is "cool" about the integration in Rails is that you can have a map 
of maps to populate an object for you like this:

obj =['object'])

Any elements input from the form for 'object' automatically get 
associated with the data elements in the MyObject instance.  This is a 
wonderful time saver, and it provides easily groked code.  Of course, 
this association is based on a naming convention that takes care of the 
abstraction.  If we ever wanted to replace a value in the request 
object, we would do something like this:

@request['name'] = val

Which means that your request parameters are not read only.  Again more 

To me, this works.  It is emensely simple, and it is yet another 
abstraction above the native CGI abstraction for Ruby code.

I'd like to see something similar for Cocoon.  Not for the 2.2 release, 
but for a future release.  I know we can't have the same syntax in Java 
that we do in Ruby, but why not allow something like this:

val = request.get("name");

obj = request.decorate( "object", new MyObject() );
// template<T> public T decorate( String name, T object );

request.put("name", value);

Just a little note about the Factory function.  If the class was a 
normal JavaBean, we could use the bean utils to set the parameters from 
the map returned from the request object.  That would keep the user from 
having to write the same code in every object they created.  It is about 
as close as we can come to adding methods to objects at runtime like you 
can in Ruby.  Defining a nice little convention like that can make 
developing in Cocoon fairly nice.

The session handling in Ruby is very much the same, so there is no point 
in going into detail there.  What is noticeable is the lack of a direct 
interaction with a response object.  I like that aspect.  That's what 
the pipelines in Cocoon are for.  I'd also like to see what we can do to 
hide any possible need for the Context object from the Servlet spec.

View raw message