cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Changing Abstraction
Date Tue, 13 Dec 2005 19:56:48 GMT
Berin Loritsch skrev:
> 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 
> flexibility.
> 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.

We could certainly have a wrapper that adds convenience methods to the 
servlet family of interfaces. As long as we get rid of the currewnt 
irritating state where you have to convert back and forth between 
unrelated interfaces with about the same methods.

> 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.

I'm against that. If we want to make Cocoon more layered and reusable, 
things become much more simple to reuse if we use the standard servlet 
interfaces. We should IMO only have own abstractions if we need 
something that is considerably different.


View raw message