cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [2.2] New processor interface/approach
Date Wed, 12 Jul 2006 08:01:07 GMT
Carsten Ziegeler skrev:
> Some time ago we discussed very lengthy that our core interface, the
> Processor, is not the best interface we ever invented. The processor
> should be the main entrance to the Cocoon processing engine.
> As I need a simple way of adding my own processor in my project, I
> started to create new interfaces and implementations which should make
> the whole thing much easier (to use and implement).
Sounds good.

> Before I go into the details, please note that these changes do not
> affect the usual Cocoon user at all. It should just clean up the core
> which is usually never used by any project. But with changes like these,
> this hopefully will change.
> I committed the new stuff as a prototype to the whiteboard
> The code is not tested yet, as I would like to discuss the things first,
> before completly implementing them.
> Ok, the new processor interface is very simply as it just has one single
> method (process) which gets a HttpServletRequest and a
> HttpServletResponse. That's it - this makes integrating Cocoon in any
> other web environment very easy and I can't think of any simpler
> interface :) Basically integrating Cocoon in another framework is then
> a) get the cocoon spring bean container from the servlet context, b) get
> the processor bean from the spring container and c) invoke the processor.
Often you are going to need the servlet configuration and/or context and 
then you are back on the Servlet interface again. OTH, having a Servlet 
as a managed component is slightly complicated as one need to keep track 
on both its life cycle as a managed component and as a servlet. I guess 
we will see which way that is best to go when you have implemented a 
little bit more.

> There might be the need to receive sax events instead of getting the
> generated content from cocoon in a stream. So you can pass in a sub
> interface of HttpServletResponse - the SAXAwareHttpServletResponse - and
> in this case the processor sends sax events to the response instead of
> writing to the output stream - I'm not sure if this makes sense, it was
> just an idea.
A good idea IMO. I considered going that way while working on the VPCs, 
but back then it seemed to be to much work as hadn't start to move 
towards the servlet set of interfaces. Instead we have a 
VirtualProcessingPipeline that contains the methods:

ordinary pipelines:
    public boolean process(Environment environment)
VPC generators (and Cocoon protocol):
    public boolean process(Environment environment, XMLConsumer consumer)
VPC transformers:
    public XMLConsumer getXMLConsumer(Environment environment, 
XMLConsumer consumer)
VPC -pipelines:
    public XMLConsumer getXMLConsumer(Environment environment)

I have never been happy with that solution and if we want to add XML 
pull processing to that we can see that we get an combinatorial 
explosion of the number of methods. Putting the knowledge of the input 
and output format into the request and responses probably results in 
much more manageable and possibly reusable code.

> Currently I have two Processor implementations. One of them is the
> sitemap processor embedding the TreeProcessor - so this is the usual stuff.
> The other processor implementation uses the mount table approach. It
> reads in an xml configuration file for the mounted sitemaps and then
> forwards the request to a sitemap processor. So instead of having a
> mount in the main sitemap, you have no main sitemap with this approach
> anymore but directly jump into the correct sitemap based on the mount
> table configuration. This can be enhanced later on to jump to a
> completly different processor which might not use the a sitemap at all.
For the generalizations that you suggest it is better to use the blocks 
architecture. Right now it is tied to OSGi and cannot be used in 2.2. 
But there are not that many dependencies, so it would not be that much 
work to make it usable in 2.2. For this there would be a dispatcher 
processor that depending on the uri prefix, dispatches to the relevant 

> So, WDYT?
Looks good.


View raw message