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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
