cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [RT] Ditching the environment abstraction
Date Sun, 11 Dec 2005 23:12:44 GMT
Daniel Fagerstrom wrote:
> 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?

The real reason why we wanted to keep the environment pluggable was that 
we envisioned cocoon as a Mailet as well. Needless to say, this never 
happened.

So, yes, I'd be very happy to get rid of yet-another-servlet-API and 
simplify things.

-- 
Stefano.


Mime
View raw message