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.
Why? I used intentionally "cocoon:/component1.html" to "reuse" the "*.html" pipeline in your helloWorld.html sample. I don't see why this processing should change anything.
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 ---+
That's only a matter of correct matching. And should not introduce any complexity besides the number of pipelines itself.
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?
I would not switch to flowscript for this.
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.
I don't want to say it is the one and only and best solution, but it is a clean replacement for map:aggregate, if that's to complex or dynamic. And if you think a for each in the sitemap would help:
<forEach component>
<map:part src="cocoon:/component.html"/>
</forEach>
then there is nearly no difference in my proposed approach IMO. What do you need: 1) a list of the components and 2) a loop over the list, 3) a pipeline for each component and 4) a post processing of aggregated components.
Let's introduce a new element into the sitemap to show the result:
<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?
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>
The other two pipelines are exactly the same. What's worse than map:aggregate about it? The componentsList2cinclude.xsl does not more than what the for-each does in the dynamic aggregate. I don't see a real difference between approaches.
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
You must not programming in XSLT of course. But is this done in the approach above? Is componentsList2cinclude.xsl programming? It's just a conversion of one XML to another. Based on templates, not instructions. XSLT is a functional language, not a declarative one. But there are people knowing more about this part than me, e.g. Dimitre Novatchev (http://www.topxml.com/members/profile.asp?id=i1005).
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.
That's exactly opposite to my experiences. 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.
If you can say what you do not like on the above presented approach, I can maybe help to resolve your doubts.
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
