cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Understanding cocoon ......
Date Thu, 10 Jan 2002 13:15:33 GMT
Christoph Henrici wrote:
>   I have been studying, testing and playing around with cocoon in the
> last few days as a newcomer : i am greatly impressed with what ease with
> cocoon "pipelines" arbrary data sources can be "chained" to a result
> target: a very powerful paradigm (pipe) applied in a powerful context
> (http) by using great technology (xml, xlst). 

Yep, I think you really hit the point. Some people believe that it's
enough to add server side transformation capabilities (say, adding a
XSLT post-processor as a servlet filter!) to come up with a publishing

But without a solid and well designed internal component architecture
this is definately not true.

> In context of the
> development of a web based application with requirements for a fairly
> generic mechanism for the dynamic personlization of webpages in terms of
> content and style the following questions below arised.  Maybe they stem
> from the fact, that i still missed a couple of aspect and points, maybe
> the requirement or idea is just not thought through enough, anyway:
> a. Is it possible to "compose" pipelines and having the composed
> pipeline beeing processing bottom-up and the whole beeing rendered for
> example as html: A compostion of tables within table, frames within
> frame etc.,  where the content of the "elementary" pipelines are
> dyanmic, taking for examples data from the databases. I am aware that
> the aggregation <map:aggregate> mechansim provides a somewhat similiar
> construction, only the composition could also be composed of aggregations.

There are two 'flavors' of aggregation in Cocoon: generation-based and

The first is done with the use of the <aggregate> semantic include in
the sitemap. In fact, an aggregator is nothing but a special generator,
but it was decided to place directly into the sitemap semantics since it
is very useful.

The problem with this approach is that the parts must be defined at
sitemap-design time. While this normally covers 90% of the cases, in
some other cases (my-netscape-like portal applications, for example) the
aggregation is driven by environment information (say: user preferences)
thus cannot be specified in the sitemap (unless everything is aggregated
and then filtered out, but this is not performant at all, expecially for
very complex portals).

For this reason, another solution is present, which is based on
server-side xinclude expansion performed at a transformation stage.

In short: the pipeline contains some namespaces that indicate 'include'
behavior and the transformer acts as an aggregator but on 'part'
information which is previously generated, so might come from any

it is easy to imagine a generator that gets the details about the user
preferences out of a session bean (or ejb, database, file, whatever) and
streams them on the pipe, letting the subsequent transformer performing
the aggregation.

of course, all this is cache-aware.

> b. Is it possible the change the sitemap or more specifically the
> piplines configuration ( <map:pipelines>)  dynamically.

No and I will continue to veto it until somebody changes my mind.

I think dynamic pipelines are *bad* and so far, nobody was able to come
up with a meaningful example that *required* dynamic pipelines and
couln't be done with better pipeline components.
> If this can be achieved with cocoon 2 i would be very grateful for a
> rough outline on how. 

Check the XIncludeTransformer and the CIncludeTransformer.

> If some additional development would be needed it
> would be great to have some starting hints at where to start looking at.
> Any other ideas or suggestions with regard to the requirement are also
> greatly appreciated.

Hope this helps.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message