Conal Tuohy wrote:
-----Original Message----- From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
<snip/>
You can do many things with XSLT, but also with Java, C, Assembler... It's just a matter of picking the right tool for the right job.That's right - that's why we shouldn't tell people "never se XSLT for inclusion". That's too dogmatic. Sometimes XSLT is the right tool.
It's correct if I tell you not to write your web application in assembler, IMO it's not dogmatic. The fact is that IMO XSLT is not the right tool for this job.
Well XSLT is not VERY much like assembler ;-)
Some stylesheets though do have the same code clarity ;-)
I've often found it necessary to use XSLT to transform a source document to use <xi:include>, but the tricky thing is when you need to do this recursively: to aggregate an entire grove of documents starting from a root document ... at each document the XSLT has to identify documents to include, and use <xsl:apply-templates select="document(@href)/> to include them recursively, or it can create the xi:include elements, but in that case (using xi:include) then you must invoke XIncludeTransformer and again the XSLT and again the XIncludeTransformer, until the tree is complete.
In the worst case (this is an actual case I had, in fact), you have a linked-list of documents. If using the XIncludeTransformer, to traverse the list n documents long (I had n>100, sometimes >200), requires n simultaneous invocations of the sitemap, XIncludeTransformer, XSLT transformer, etc. In most cases though you would be traversing a much shallower grove.
I've lost the code I wrote, but I'll recreate it and post it to the list ... it was very small and tidy and worked pretty well (apart from the caching problem) - it didn't violate SoC in any signifant way I could see.
It seems you didn't because you used solely XSLT as an addvanced xinclude.
Well, the main problem with using XSLT for aggregation is that you can simply use also the other things that don't only aggregate, and this is really asks for abuse ;-)
Instead, if I define my XSLTI xml syntax, limited to defining tags that include, and then use XSLT underneath as a motor, but without having the user use it directly, I have effectively wrapped it.
Hmmm ... I think this is an interesting idea. It could be implemented as a compiler, with its own pipeline:
<map:match="xslti-to-xslt/**"> <map:generate src="xslti/**"/> <map:transform src="xslti-to-xslt-compiler.xslt"/> <map:serialize/> <map:match>
<!-- and to call the compiler, e.g. when aggregating a website: --> <map:match="traverse-website/**"> <map:generate src="{1}" type="html"/> <map:transform src="cocoon:/xslti-to-xslt/html-post-order-tree-traversal.xslti"/> <map:transform src=" </map:match>
HA :-)
Interesting solution, why don't you do it?
It could be the first real Cocoon mini block, ie cocoon sitemap that becomes a block used by another sitemap.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------