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 = MyObject.new(@request['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.
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.
