Re: [RT] XSL structure across projects -- was -->Re: HTML/CSS and graphics

[Bert Van Kets <be...@vankets.com>]

At 02:51 24/05/2002 -0700, you wrote:
>Hi folks,
>
>Steven Noels wrote:
>
>>On Thu, 23 May 2002, Robert Koberg wrote:
>>
>>
>>
>>>>If they can create their own XSLT, perhaps there should be 
>>>>xml-apache-rules (already in place?) about xsl:include vs. xsl:import 
>>>>and/or using a priority attribute on a template rule to override the 
>>>>base set of XSL.
>>>>
>>
>>We should be cautious on xsl:import/include since this conflicts with 
>>stylesheet caching... same with the document() function - to be avoided 
>>if possible. Think about this before choosing a direction.
>
>I have been looking for a way to use componetized XSLTs without 
>include/import. I see how Forrest uses book2menu which does an inital 
>transformation producing a new result which is then transformed again. Is 
>this considered the correct way to handle component XSLT?
>
>Someone on the user list suggested that I use a pipeline to aggregate the 
>XSLT, is there an example or thread you can point me to (I cannot find 
>info and can't find it in my hacking)?

IMHO The best way of putting things together in Cocoon (Forrest is a Cocoon 
implementation/application) is using pipelines.  The docs section of the 
Cocoon site is built up this way. Check out the sitemap in the 
Cocoon/documentation directory.
If you really need to merge XSLT's you need to have a look at 
<map:transform src="cocoon:/yourpipeline"/>  where "yourpipeline" points to 
a pipeline called "yourpipeline".  In that pipeline you aggregate the 
different XSLT's.  XSLT is after all a form of XML.

Bert