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
http://svn.apache.org/repos/asf/cocoon/whiteboard/processor/
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
BlockServlet.
So, WDYT?
Looks good.
/Daniel
