cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph Henrici <chenr...@dplanet.ch>
Subject Re: Understanding cocoon ......
Date Thu, 10 Jan 2002 20:46:01 GMT
Stefano Mazzocchi wrote:

>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
>framework.
>
>But without a solid and well designed internal component architecture
>this is definately not true.
>
You definitely miss  a framework with a high degree of reusability, 
entensability and a high degree
of configurability achieved through the component architecture. It' s 
like with all, you start with solving
specific problems and as your requirement space grows you evolve at 
least the paradigm: good software has
to make well balanced decisions between meeting specific requirements 
and generic solutions. I think cocoon 2
achieves this extremly well, especially now with the understanding of 
 your below elaborations.

>>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
>transformation-based.
>
>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
>source.
>
>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.
>
Yes, i agree now, understanding very much more about the two approaches 
to aggregation.

>>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.
>
I'll do that ....combined with the generator based approach, maybe even 
combined with a
aggregation / filter approach ......

>>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.
>
Yep, definitely.
Christoph Henrici


Mime
View raw message