<map:aggregate element="StaticPage" prefix="exp" ns="http://konova.com/ns/expedition/expedition"; label="aggregatePage"> <map:part src="cocoon:/helloWorld.html"/> </map:aggregate>
Later in an internal-only pipeline:
<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>
Why? Because as I mentioned in my last post, using CInclude is really messy; difficult to manage, maintain, and debug; slow to process; and just plain frustrating!
Hmm, we have used cinclude massively ourselves and I never had the feeling that it is difficult to maintain or slow. Maybe you show us your cinclude pipeline tries to?
It should be like the following:
<map:generator src="dynamicComponentsList"/> <map:transform src="componentsList2cinclude.xsl"/> <map:transform type="cinclude"/> map:serialize type="html"/>
The componentsList2cinclude.xsl creates an XML like the following:
<page xmlns:c="http://apache.org/cocoon/include/1.0";> <c:include src="cocoon:/component1.html"/> <c:include src="cocoon:/component2.html"/> <c:include src="cocoon:/component3.html"/> </page>
I can not think of something much more cleaner than this one. The XSL itself might be some more complex but this depends only on your dynamicComponentsList XML file format. The creation of elements as you did it above in the helloWorld example should be similar for cinclude.
Joerg
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
