cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: The real Processor concerns
Date Tue, 11 Oct 2005 17:36:19 GMT
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


Mime
View raw message