cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject [RT] Ditching the environment abstraction
Date Sun, 11 Dec 2005 17:56:17 GMT
It seem like we all agree about that the Cocoon core need to be 
simplified, although we have different opinions about how to achieve it. 
IMO it can be done in steps by refactoring of the trunk.

One of the complications with Cocoon is the environment abstraction: 
o.a.c.environment.Request, Response, Context etc. They are similar but 
not identical to the javax.servlet and javax.servlet.http interfaces, 
which means yet another thing to learn for the user. It also means that 
it becomes more complicated to use externally developed components, as 
these typically implement the servlet family of interfaces. Furthermore 
it leads to a more complicated setup process of Cocoon.

So, do we need this extra layer of abstraction? It made sense when 
Cocoon was mainly a publication framework, for publication the servlet 
family of interfaces has a lot of functionlity that is irrelevant. But 
now when Cocoon has developed to a webapp framework, it makes much less 
sense to have an own abstraction of what already has a standardized 
abstraction. o.a.c.e.Request has expanded so that it is close to 
identical to HttpRequest. For o.a.c.e.Response and Context there are 
larger differences to their servlet counterparts, they are subsets. But 
what is not implemented either could be implemented or just throw an not 
implemented exception.

Another reason for having an own abstraction was to be able to use 
Cocoon in none servlet environments. This has not happened to any large 
extent, in addition to the Http environment, we have CLI, Faces and 
Portal environment. For the Http, Faces and Portal environment, using 
the servlet interfaces should be a simpilification and improvement. For 
CLI, I dont see that it would complicate anything either.

The main problem with swithing to the servlet interfaces AFAICS, except 
for that it takes some work, is back incompability. This could be solved 
to some extent by letting our abstactions extend the servlet interfaces. 
Nearly all methods have the same names and types. But IMO it would be 
better to simplify Cocoon and take the back incompability now and just 
remove our own abstraction, we could have some adapter utilities in some 
compability block.

So in a first step I would like to switch our environment abstraction to 
their servlet correspondances.

In an next step I think we should use Servlet instead of processor for 
our "controllers": Cocoon, Sitemap, Flow and possibly the Pipeline. This 
would make it simpler to reuse Cocoon functionality, and also to 
experiment with new kinds of controllers. As discussed before the 
Processor interface contains a far to much implementation details that 
are connected to sitemap engine internals for beeing suitable as a 
general controller interface within Cocoon.

I'm considering to reimplement the two controllers in the blocks 
architecture: the BlocksManager and the BlockManager, as servlets, and 
thus get rid of a lot of start up complications. Also it would make it 
possible to let a block contain any servlet with a set of components, 
instead of hardwiring it to the sitemap controller.

WDYT?

/Daniel

Mime
View raw message