cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] the quest for the perfect template language
Date Fri, 04 Apr 2003 10:48:30 GMT
Robert Koberg wrote:

>>>Daniel Fagerstrom wrote:
>>>"request::lang" etc, could be translated to the the XSLT function
>>>"document(request:/lang)", where "request:" is a Source. With the new
>>>Source and XSLTProcessor implementations from excalibur we get cashing
>>>for free if the parameter to the document function is determinable at
>>>compile time.
>>oh, yes, I thought about that too, but, gosh, I hate document() so much.
>>What about XSLT extensions?
> What is the difference, other than mixing concerns (java inside of XSLT) and
> lack of portability between XSL processors? With document(), you can do
> EXACTLY the same thing as you would with an extension. You send a specific
> request to the server (while transforming on the server or not). The server
> will/could ONLY handle specific types of requests through it's URIResolver.
> I just don't get it... 


> I can't see any good time to use an extension. If you need a simple string,
> int, Boolean, whathaveyou - pass it in as a param. If you need an array, or
> something hierarchical turn it into XML and feed it to the document call.
> This seems to me to be a perfect match for cocoon.

Two things worry me:

  1) performance: document() is a push-based function. We can't have a 
call to a cocoon pipeline for each and every variable I need.

  2) caching (related to the above): how do I know if the result is 
cacheable if I have no hooks to the document() engine?


View raw message