cocoon-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: FAQ and snippet, document() function
Date Thu, 11 Jul 2002 09:28:22 GMT


Conal Tuohy wrote:
>>-----Original Message-----
>>From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> 
> 
> <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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


Mime
View raw message