cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject [2.2] New processor interface/approach
Date Tue, 11 Jul 2006 20:20:05 GMT
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).

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.

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.

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.

So, WDYT?

Carsten
-- 
Carsten Ziegeler - Open Source Group, S&N AG
http://www.s-und-n.de
http://www.osoco.org/weblogs/rael/

Mime
View raw message