In general I agree with this - it makes learning Cocoon internal a little bit easier. But I think the current environment api is not our biggest problem. Anyways, our current Request object has more functionality as the servlet request object, e.g. to get the sitemap prefix and sitemap uri and more important the request attribute handling for internal requests. How can we keep this functionality when switching to the servlet api?
And for me the most important question :) What is the suggested timeframe/version for this? Do you want to do this for 2.2? Or for a later version? Carsten 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? > > /Daniel > -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
