cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Dumon <br...@outerthought.org>
Subject RE: Crusading for the XSLT document() function
Date Mon, 20 Oct 2003 14:02:00 GMT
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
bruno@outerthought.org                          bruno@apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org


Mime
View raw message