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.
- Re: [RT] Ditching the environment abstraction Stefano Mazzocchi
-
