cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Koberg <...@koberg.com>
Subject Re: [report] xml-site update
Date Sun, 02 Jun 2002 07:47:32 GMT
Hi,

Steven Noels wrote:

>Rob,
>
>>I don't suppose anybody else could address the issue. Or is Steven the
>>only one? I believe he was the one who gave the advice to not use
>>document and include/import. Do others feel that you can/should use
>>    
>>
>these?
>
>If document() and xsl:import/xsl:include is what you want, i.e. putting
>everything in one big XSLT transformation (which might be technically
>possible but hard to maintain), 
>
It certainly is technically possible (many people already do it this 
way). As for maintenance, I don't understand why you think it is more 
difficult to maintain.

>instead of using the Cocoon pipeline and
>aggregation approach, I think it will be hard to find partisans for this
>on this or Forrest's list.
>

I really want to understand why it is better to use pipelines and 
(sitemap) aggregation in the case of the forrest project.

Anyway... the actual question(which seems to get ignored...) I have been 
asking was: if not this way then how is a cocoon app (forest in 
particular) supposed to handle things that are commonplace in XSLT.  

For example, the first question was about xsl:import/xsl:include. I 
offered componentized XSLT for forrest - very clean and very easily 
maintained. You are saying it is easier to maintain by aggregating these 
things through the sitemap rather than using a simple <xsl:include 
href="banner.xsl"/>. Why is it easier to maintain with aggregation?

The second question had to do with using information from the book.xml 
to provide link information (through XPath's document function). 
Currently you hard-code those links. That is hardly something that can 
be considered easily maintainable. How will forrest handle this?

I wanted to provide help to the project but it is set up in a way that 
is very counterintuitive to me.

best,
-Rob



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message