I can't tell you how much your comments are helpful to me!! Thanks!!!
The following sums up very well what I am attempting to do.
> <map:match pattern="index.html">
> <map:aggregate>
> <map:for-each src="cocoon:/componentsList.xml">
> <map:part src="{componentname}.html"/>
> </map:for-each>
> </map:aggregate>
> <map:transform src="doWhatEverPostProcessing.xsl"/>
> <map:serialize type="html"/>
> </map:match>
>
> <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>
>
> <map:match pattern="componentsList.xml">
> <!-- where ever we will get this from,
> let's assume from file system,
> though not very dynamic -->
> <map:generate src="componentsList.xml"/>
> <map:serialze type="xml"/>
> </map:match>
>
> IMO that's really a short, nice sitemap snippet, that might work.
> If you need individual pipelines for the components, just add them.
> Do you like it or does this approach already have weaknesses?
No, this is perfect!
> Now cinclude. It's nearly the same! With the advantage that it works.
>
> <map:match pattern="index.html">
> <map:generate src="cocoon:/componentsList.xml"/>
> <map:transform src="componentsList2cinclude.xsl"/>
> <map:transform type="cinclude"/>
> <map:transform src="doWhatEverPostProcessing.xsl"/>
> <map:serialize type="html"/>
> </map:match>
Ok... there's just one point that I'm not "getting" here...
In the fictional sitemap above, since we are iterating through each of the
components in componentsList.xml, we are calling a separate pipeline each
time and processing each component individually, exactly like the conceptual
ASCII diagram I drew last time:
Main pipeline +-------->
| ^
+- pipeline A ---+
+- pipeline C ---+
... |
+- pipeline n ---+
However, in the CInclude example, we're acting on the entire set of
components all at once. IIUC, this approach requires me to process all the
components together as a block in the same pipeline. So:
Main pipeline-->process A-->process B ... -->continue as above
In other words, the first apporach is more parallel (and easier to design,
code, and maintain), while IIUC the second example does EVERYTHING in
series.
Or am I missing something?
> The better the XSLT is in regard to "not programming", the better
> it is in regard to maintainability *and* performance. I can not
> judge about your experiences with XSLT, so don't take the next
> sentences as addressed to you. But I know that mostly the same
> errors are done with XSLT, and mostly this starts with the
> XPathes: descendant axis starting at root (//*), preceding and
> following axis instead of their -sibling companions, ancestor
> instead of parents, etc. If one starts to use xsl:if/choose/when
> massively, something is wrong! That's really programming. But
> we leave this list's topic to much.
I know this strays a bit from this list's main purpose, but if you could
point me to some references (books, websites, articles, whatever!) that
discuss some of these topics, I would be very grateful. I've tried looking
around, but I guess I haven't been looking in the right places. :-(
I have fallen into a lot of these traps myself, so if I can learn from the
experiences of others before having to make more errors (pretty much the
definition of a design pattern, I'd say), I would be very thankful!
Thanks so much for all your help!!
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
