On 11.05.2004 03:33, David Leangen wrote:
<snip what="aggregate sample"/>
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.
<snip what="cinclude sample"/>
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:
It's not the aggregate/part itself that calls the separate pipelines, it's the cocoon:/ pseudo protocol. And this can be used in cinclude too. g[R]ek gave an example for it.
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
No, I would draw also the same diagram for cinclude. If you have 5 cinclude statements like
<cinclude:include src="cocoon:/component.html"/>
in the XML you make 5 subrequests (or internal requests) to the "*.html" pipeline - or another one, depends simply on your matchers.
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.
Both are technically the same, the one aggregates pipeline results, the other includes them, but that's only a naming issue.
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!
Writing good XSLTs is heavily experienced-based. I also did not find any XSLT-patterns resources until now. I learned XSLT on the Mulberry XSLT list (http://www.mulberrytech.com/xsl/xsl-list/). That's a very good resource with the best XSLT-writers offering their help: Michael Kay, David Carlisle or Jeni Tennison (http://aspn.activestate.com/ASPN/Mail/Leaders/XSL-List), but learning from a mailing list, i.e. by other ones' use cases, is of course very time consuming. From this list I know that Jeni Tennison is a very good explainer and I heard her books are good as well. She has one book for beginners: http://www.amazon.com/exec/obidos/ASIN/1861005946/ and one for advanced users: http://www.amazon.com/exec/obidos/ASIN/0764547763/. Michael Kay's reference is also recommendable: http://www.amazon.com/exec/obidos/ASIN/0764543814/. Then there is a FAQ on XSLT maintained by Dave Pawson, which is more or less a best of Mulberry XSL list, but you need to know what to search for: http://www.dpawson.co.uk/xsl/sect2/sect21.html. And not to forget the specs on XSLT and XPath, they are readable and not that long:
http://www.w3.org/TR/xslt and http://www.w3.org/TR/xpath.
Hope this helps,
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
