On Mon, 2003-10-20 at 15:49, Lars Huttar wrote: <snip/> > E.g. the response to my report of an apparent bug > in Cocoon's handling of a document() URI, in the > "problem with relative URI in document() in XSLT in Cocoon" thread: > > > You shouldn't use document() in Cocoon style sheets anyway, for a > > variety of reasons, one of them bein problems with caching. > > Use <map:aggregate>, XInclude or CInclude instead. > > When I explained that this was a case where caching was not a problem, > and asked for any other reason why I should avoid document() (or, > I should add, why I shouldn't expect document() to work according > to the XSLT spec), there has been no further response. > I can understand why one poster felt that minds are closed on > this issue. Obviously not all minds, but... >
Caching with transformers that perform some kind of inclusion is currently a problem in Cocoon, but so far it hasn't annoyed anyone enough to solve the issue (though there's been lots of complaints from users). Note that the XIncludeTransformer also isn't cacheable, and while the CIncludeTransformer does some sort of caching it's not really like one would expect (namely that the cache becomes invalid when one of the included sources changed). Solving this would require some changes to Cocoon's caching system. However, in your case you don't need caching, which you can easily work around with by putting the pipeline inside a <map:pipeline> with an attribute type="noncaching". > > > Whether one likes it or not, we have seen huge performance gains by > > minimizing the number of XSLT transformations in a pipeline, > > even at the > > end of building one-off custom SAXTransformers to replace some XSLT > > stylesheets. > > Cool. > > > Cocoon is XML-centric, and might be a nice > > environment to > > do server-side XSLT transformations, but I find it difficult to state > > that XSLT (and the document() function) is the panacea for all webapp > > development related problems, or more specific aggregation, > > or whatelse. > > Agreed, document() isn't the best tool for all cases. > > My understanding is that this "crusade" was not to spread the > use of document() to all cases, but to rescue it from being > bluntly disparaged even in the cases where it's useful, fwiw, that was also my understanding of it, and I agree with it. > and > from being poorly supported. > > That's my point anyway, i.e., if Cocoon is XML-centric and > uses XSLT a lot, it would seem pretty important that document() is > handled correctly even if there are cases where it shouldn't be used. > > > That being said, if anything is missing w.r.t. document() / Source / > > caching support in Cocoon (or Xalan!), I'm pretty sure > > patches will be accepted gratefully. > > OK. > I guess I should submit a bug report to bugzilla. (That's all I can do.) there is/was already one, but it was then closed an moved as a feature request to a wiki page: http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatureRequests -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
