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...
hmmmm
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?
Stefano.
