Hi, > -----Original Message----- > From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 03, 2002 8:15 AM
> Robert Koberg wrote: > > >>The problem is conceptual, that document() breaks SoC, as described at > >>http://localhost:8787/cocoon/documents/faq/faq-xslt.html#faq-6 Hopefully > >>things like XPathTransformer will remove the need for document() > >>altogether. > > > > > > Yea, I have heard the argument. > > > > I just don't understand why you can't use XSL to separate out some these > > concerns. > > Don't use Cocoon then, use XSLT. > You can use XSLT extensions instead of the DB Generator, make your own > extensions instead of XSP taglibs or use document() for aggregation. > > Why use Cocoon at all? For three resons: 1. It does some things really well 2. Some things should not be done in XSL 3. I know I will have clients who will want to use it > > > Hmmm... one line of XSLT v. (at least) one class > > > > Perhaps (the general) you could create a 'business-logic' directory and put > > these 'worker' XSLs in it to avoid the cognitive dissonance. > > > > XSL has many uses, why psuedo-cripple it? > > You need the right tool for the right job. very true > > This transformer, if done well, can be faster, more efficient than xslt, > which is more general-purpose. I guess I would like to see the numbers on this for the entire transformation. > > Anyway, it isn't compulsory, you can use whatever you prefer. Yes, I know. That is why I originally responded with a 'For the record.' But, for some reason, I bristle when SoC is invoked in a dogmatic way. I wish cocoon's best practices would include using the document function (and xsl:include/import) where appropriate. best, -Rob --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
