cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Leangen" <>
Subject RE: Dynamic aggregation
Date Mon, 10 May 2004 23:49:21 GMT

Ok, thanks Jeorg!

What you describe below seems to make good sense in the case that each XML
file doesn't need any additional processing.

However, in this case, each "component" needs to be processed individually
first. I need to generate a separate pipeline for each part, then merge them
at the end in the main pipeline. Here's another attempt at ASCII art:

Main pipeline      +-------->
  |                ^
  +- pipeline A ---+
  +- pipeline C ---+
        ...        |
  +- pipeline n ---+

I tried this using the CInclude approach, and that's when things began to
get very messy.

So, if possible, I'd like to maybe send off each sub-pipeline to a separate
thread, then aggregate them into the main pipeline for final processing. I'm
just not sure how to do this. Maybe ProcessPipelineTo in my flowscript would
work, but I'm not sure about the best way to do this. Any ideas?

However, if you say that you've done this type of thing using CInclude as
you describe below and that you've never encountered any problems, then I'll
have another look at what I've come up with and maybe try some major
refactoring or something.

This is a bit off topic, but in my current work is related to my impression
of this approach. I have mostly been unhappy with extensive use of XSLT
because I've found that "programming" in XSLT makes it very difficult to
follow good software design practices (such as high cohesion, low coupling)
and makes things very difficult to maintain. I think that my attempts to
make the code more easily maintainable have had some serious consequences on
performance. Correct me if I'm wrong, but I get the impression that
"programming" in XSLT requires a choice between maintainability or
performance. It seems to me that one can't have both... And there aren't yet
any good design patterns to help guide me, either.

Anyway, I'm interested in hearing other people's experiences and comments on
this issue...

> -----Original Message-----
> From: Joerg Heinicke []
> Sent: May 11, 2004 8:24
> To:
> Subject: Re: Dynamic aggregation
> On 10.05.2004 00:42, David Leangen wrote:
> > <map:aggregate
> >   element="StaticPage"
> >   prefix="exp"
> >   ns=""
> >   label="aggregatePage">
> >   <map:part src="cocoon:/helloWorld.html"/>
> > </map:aggregate>
> > Later in an internal-only pipeline:
> >
> > <map:match pattern="*.html">
> >   <map:generate type="jx" src="components/{1}/component.jx"/>
> >   <map:transform src="components/{1}/transforms/html/doLayout.xslt"/>
> >   <map:transform
> src="components/{1}/transforms/html/doPresentation.xslt"/>
> >   <map:transform src="context://util/stripNamespaces.xslt"/>
> >   <map:serialize type="xml"/>
> > </map:match>
> > Why? Because as I mentioned in my last post, using CInclude is
> really messy;
> > difficult to manage, maintain, and debug; slow to process; and
> just plain
> > frustrating!
> Hmm, we have used cinclude massively ourselves and I never had the
> feeling that it is difficult to maintain or slow. Maybe you show us your
> cinclude pipeline tries to?
> It should be like the following:
> <map:generator src="dynamicComponentsList"/>
> <map:transform src="componentsList2cinclude.xsl"/>
> <map:transform type="cinclude"/>
> map:serialize type="html"/>
> The componentsList2cinclude.xsl creates an XML like the following:
> <page xmlns:c="">
>    <c:include src="cocoon:/component1.html"/>
>    <c:include src="cocoon:/component2.html"/>
>    <c:include src="cocoon:/component3.html"/>
> </page>
> I can not think of something much more cleaner than this one. The XSL
> itself might be some more complex but this depends only on your
> dynamicComponentsList XML file format. The creation of elements as you
> did it above in the helloWorld example should be similar for cinclude.
> Joerg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message