Hello everyone! I'd just like to thank you all for your input on this thread.
Lars interpreted my email correctly as a request not to exclude the document() function - not that it is a panacea. Robert - thanks for championing for the responses. You mentioned not being 'locked-in' to Cocoon by using XSLT instead of custom Java components, and that is a very useful feature. Bruce - I agree - I like the flexibility of XSLT under Cocoon. Steve - sorry for any FUD that got spread! Your points on the use of document() hiding away the aggregation instruction from where you would expect to find it (the sitemap) is very true; which is why I always pass in the location as an XSLT variable. With Bruno's post the conversation moved to center on the caching issue that Steve brought up. I did a little snooping in the code: Caching in Cocoon is performed by recording SAX events into a store from which it can then be played back. Cocoon stores these SAX caches tied to a CacheValidity object, which is provided by Cacheable components at pipeline setup time. A reference to this object is maintained throughout a single use of the pipeline component. By updating this reference Cocoon can store caching information determined after pipeline setup; since Cinclude instructions are embedded in the source document, this must be how the CInclude transformer works. The transformer for XSLT is an Avalon framework TRAX transformer wrapper, which means it knows nothing about Cocoon. A source resolver is provided to the component to allow external URIs to be determined. The component reciprocates with a CacheValidity object. This SourceResolver is part of Cocoon and therefore could monitor for URI accesses. The CacheValidity object could then be updated in a similar fashion to the CInclude transformer. CInclude aggregation and XSLT aggregation differ because under XSLT you can dynamically select the URI to be accessed using stylesheet variables. CInclude is guaranteed to access a static set of URIs. If you cannot guarantee this, you cannot cache, because you cannot determine ahead of time what to retrieve from the Store. For highly scalable web-applications you need caching, and you need to eliminate heavy-weight pipeline components in general [thanks Steven]. The flexibility of XSLT in Cocoon certainly allows you to break SoC and to break caching ( were it implemented ), but to me, I think that that very flexibility can outweigh the risk, especially for that set of URIs that don't need to be scale so greatly. One day perhaps the distinction won't arise, until then: Thank you all for this discussion! Kind regards, Peter P.S. My apologies if I missed anyone. -------------------------- Peter Horsfield http://xml.grumpykitty.biz/ -----Original Message----- From: Robert Koberg [mailto:[EMAIL PROTECTED] Sent: Monday, October 20, 2003 10:42 AM To: [EMAIL PROTECTED] Subject: RE: Crusading for the XSLT document() function Hi Lars, Are you using XSLTC? Have you tried the regular xalan or saxon? I remember reading recently on xalan-dev about a bug in relative path resolution in xsltc. Also xsltc and regular xalan use two different ways of assigning the URIResolver. Perhaps cocoon is geared toward one or the other. Saxon has the best solution (it uses both ways) so it might be the best choice. I have posted some info on both commons-dev and xalan dev about the issue that should be in the archives but if you want further info, let me know. Best, -Rob > -----Original Message----- > From: Lars Huttar [mailto:[EMAIL PROTECTED] > Sent: Monday, October 20, 2003 7:29 AM > To: [EMAIL PROTECTED] > > > From: Bruno Dumon > ... > > 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". > > Thanks, I will try that. > > > > 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 > > I saw this one, which says > > # Modify the caching system so that it is possible to: > > * include docs referenced by XSLT's document() in the cache validity > (bugzilla 10203) > > But I don't think that covers the problem I'm referring to... > please correct me if I'm wrong. > This "feature request" sounds like it's asking for Cocoon to keep > track of whether the document accessed by document() from a stylesheet > has been modified; the only problem this feature is intended to solve, > if I understand it, is that a certain request might return old data > when the referenced document has been changed. > > The problem I'm referring to is one where document() doesn't find > the requested document in the first place, due to faulty URI-resolution. > > Anyway I submitted bug report 23939 before I saw your latest email. > I hope it can be distinguished from the above feature request. > > Lars > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
