I have also thought about the Processor interface while working on the
blocks architecture and other core related stuff.
Processor is a fat interface with a lot of implementation details
shining through and that is also the case for a number of other
interfaces in the Cocoon internals. I'm sure that there was good reasons
(or laziness) behind all the additions to all the internal interfaces.
I'm responsible for some of them.
But the end effect is that it is very hard to understand what is going
on inside Cocoon, and it is a really frustrating experience to add new
functionality. It also means that it requires a huge effort to come to
the point where it is possible to start contributing to the Cocoon
internals.
IMO we need serious refactoring of the internals, and we need to start
to care about the interafaces and try to make them really minimal. For
Processor and a number of other internal interfaces we, IMO, don't need
to care for back compability, they are so complicated so it is
improbable that there are any implementations outside Cocoon.
Berin Loritsch wrote:
Based on the calls from the whole of Cocoon, the core Processor
Interface is:
interface Processor
{
InternalPipelineDescription buildPipeline(Environment env);
boolean process(Environment env);
}
I would like to go even further. Throw away the Processor interface and
use Servlet instead. Now we have our own environment abstraction. It
probably helped things when Cocoon mainly was a publishing framework,
but now when it is a webapp framework we have added one servlet method
at the time so that the Context, Request and Response interfaces in
Cocoon are very similar to the corresponding Servlet methods. We could
just let our abstractions implement the Servlet ones. For the few
methods that not are relevant in Cocoon we can throw not implemented
exceptions.
By doing that we get a whole new level of reusability in Cocoon. The
blocks architecture as an example could be used together with any servlet.
Connecting to your RoR inspired work we could start to become more
mainstream and think in terms of MVC. We could have a sitemap controller
implementing Servlet, a Flowscript controller implementing Servlet and
just redirecting to other servlets. A convention controller for RoR
style implementing Servlet. A pipeline Servlet etc.
(Note: I would separate out the InternalPipelineDescription object
into its own class)
Who calls these methods?
* the core Cocoon object
* the CocoonWrapper object
* The BlocksManager(s) objects
The getContext() method is used by the BlockManager(s) objects
In the BlockManager it is only used in a debug message, no need to keep
that.
The CocoonWrapper and the CLI in general needs refactoring, it
reimplements a lot of things that is implemented in Core, CoreUtil and
Settings.
...
/Daniel
