Today I have added Corona to our whiteboard section in SVN
(http://svn.apache.org/repos/asf/cocoon/whiteboard/corona/). It mostly mimicks
the existing concepts of pipelines and sitemaps as you know from Cocoon 2.x. The
available test cases are a good starting point to explore the sources. We also
hope that this email explains some of our ideas.
What does already work?
=======================
PIPELINE API
°°°°°°°°°°°°
So far we have created a (minimalistic) pipeline API (o.a.c.c.pipeline.Pipeline
[1]) that works based on two fundamental concepts:
1. The first component of a pipeline is of type
o.a.c.c.pipeline.component.Starter. The last component is of type
o.a.c.c.pipeline.component.Finisher.
2. In order to link components with each other, the first has to be
a o.a.c.c.pipeline.component.Producer, the latter
a o.a.c.c.pipeline.component.Consumer.
When the pipeline links the components, it merely checks whether the above
mentioned interfaces are present. So the pipeline does not know about the
specifc capabilities or the compatibility of the components.
It is the responsibility of the Producer to decide whether a specific Consumer
can be linked to it or not (that is, whether it can produce output in the
desired format of the Consumer or not). It is also conceivable that a Producer
is capable of accepting different types of Consumers and adjust the output
format according to the actual Consumer.
There are SAX-based components that implement these concepts.
These concepts are more general than the implementation of Ccooon 2.x which has
explicit methods to set generators, transformers, serializers and readers on
pipelines.
SITEMAP
°°°°°°°
The sitemap engine works similar like Cocoon 2.x. The
o.a.c.c.sitemap.SitemapBuilder reads XML and creates a tree of
o.a.c.c.sitemap.node.SitemapNode objects that know their parent node, their
child nodes and their parameters.
The o.a.c.c.sitemap.node.AbstractSitemapNode handles the node relationships and
parameters in a general way.
However there are two annotations (@o.a.c.c.sitemap.node.annotations.NodeChild
and @o.a.c.c.sitemap.node.annotations.Parameter) to make the access of specific
child nodes and parameters more explicit.
The ChildNode annotation can be used to store a certain child node in a separate
member variable instead of the collection of all children (e.g.
o.a.c.c.sitemap.node.PipelineNode receives its ErrorNode in the errorNode member
variable).
The Parameter annotation works the same way, but causes parameters to be stored
in separate member variables (e.g. o.a.c.c.sitemap.node.MatchNode receives its
pattern in the pattern member variable).
When the sitemap is being executed, the invocation traverses the tree of
SitemapNodes. Each node returns a o.a.c.c.sitemap.node.InvocationResult that
indicates the execution state. This is one of NONE, PROCESSED, and COMPLETED:
* NONE means that the node did not do any processing whatsoever (e.g. a
MatchNode did not match).
* PROCESSED means that the node did some processing, but the traversal should
continue (e.g. the GenerateNode installed a Generator at the pipeline; but some
other components might still be pending)
* COMPLETED means that the node did some processing and the traversal should
stop, since the invocation processing is completed (e.g. the PipelineNode
executed the pipeline)
Nodes that act as a switch (e.g. MatchNode, ErrorNode, etc.) aggregate the
individual results of their children.
So a MatchNode will respond with NONE if and only if all of its children return
NONE, and with COMPLETED otherwise.
EXECUTION CONTEXT
°°°°°°°°°°°°°°°°°
When a pipeline and then further the sitemap is invoked, the execution context
is passed. Since context has so many different meanings to us, we called this
execution context o.a.c.c.sitemap.Invocation. It contains input parameters,
sitemap parameters and a component provider and gives access to the result.
Since the sitemap should be useable in any environment, the Invocation doesn't
have any environment specific dependencies (e.g. the Servlet API). Hence, the
input parameters are a general map. However, our idea is that environment
specific parameters (e.g. the HTTPRequest) can be put into this map too and can
be made accessible by an accessor helper class.
So if a component needs access to environment specific parameters e.g. the
HTTPRequest, it uses the appropriate accessor helper class. All components and
accessor helper classes that belong to a certain environment (iow. are not
generally available) should be bundled together. This creates a core module that
is useable in any environment and additional modules for specific purposes.
Since the sitemap shouldn't depend on a specific component container, the
o.a.c.c.sitemap.ComponentProvider as an abstraction for specific containers, was
introduced. So far we have implemented a o.a.c.c.sitemap.SpringComponentProvider
that encapsulates all Spring bean lookups. It should be fairly easy to write
implementation for alternative containers (e.g. OSGi).
What needs to be done?
======================
So far the package and module structure doesn't reflect all the ideas from
above. For now we have prefered to keep the things simple.
The sitemap language hasn't been completed so far. We also think that we should
take this as a chance to tidy up a few things (e.g. map:match vs map:select,
map:call).
There are still many components missing. For our needs we will work on the
XSLTTransformer and the IncludeTransformer.
There is no support for other expression languages (e.g. JEXL, JXPath) than the
"map" language.
We want to introduce support for controllers, however, we are not sure if this
should be a environment specific concept or should only go into a servlet
specific module. (So far we don't have any use case for it outside of a web
application.)
Caching pipelines are not supported yet.
As I said (http://marc.info/?l=xml-cocoon-dev&m=120542286521032&w=2), our goal
is to get the Micro-Cocoon test sitemap[2] working.
We hope that this gives you enough hints in order to understand Corona. We are
very interested in further discussions. So fire at will!
Reinhard & Steven
[1] o.a.c.c -> org.apache.cocoon.corona
[2]
http://svn.apache.org/repos/asf/cocoon/whiteboard/micro/misc/cocoon-micro-it-block/src/main/resources/COB-INF/sitemap.xmap
--
Reinhard Pötz Managing Director, {Indoqa} GmbH
http://www.indoqa.com/en/people/reinhard.poetz/
Member of the Apache Software Foundation
Apache Cocoon Committer, PMC member, PMC Chair [EMAIL PROTECTED]
_________________________________________________________________________
