Robert S. Koberg wrote: > I (and probably many other XSLT-heavy folk) would very interested to > know the best practices for cocoon shown in way that takes an XSLT > based site and produces a best-practices cocoon based app. (I would > love to see how Jorge Pietschman builds cocoon apps)
It's interesting, because most of my work with cocoon has been java-based.. giving an object layer above a database schema, and assigning a transformer to look for certain xml elements, which then hands off the element and any sub-elements/attributes to another class, which takes care of spitting out the database-specific SAX elements into the stream. Are we violating best practice, or is this just another approach? We kind of like it:) > For example: > - why is xsl:include and xsl:import bad -> how should it be done this is bad? hrm. There was another thread about how included/imported stylesheets don't get refreshed right away, but that bug has been fixed by Carsten apparently in the 2.0.3 code (or so says a recent thread). Are there other reasons this is bad? Are there other more desired solutions (other than sticking everything in the same XSL doc, or making multiple entries in the sitemap)? I'm interested. I've always used XML as a template of sorts (I'm currently trying to minimize the number of XML docs so that there are less changes to be made in updating them, and from what I read, I don't think aggregates will do it for me, nor am I sure I agree with the philosophy). Liam Morley --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>