Mark Lundquist wrote:
On Jun 19, 2005, at 11:53 PM, Geert Josten wrote:
Hi Mark,
OK, if I have to use a pipeline for this, I would use the module
source, e.g.
<match pattern="globals/*">
<generate src="module:global:{1} />
<serialize type="xml" />
</match>
That oughta work, right?
Ah, never too late to learn something new. Though, this generates only
one global. If that suits you, then go ahead. :)
Well, that is true. It suits me today, but it might not some other
time! So, I've made a change enabling this:
<generate src="xmodule:global:"/>
That generates a SAX stream containing all the globals. I will make up
a patch and see if the powers that be like it :-)
By the way, make sure that the parameters pipe is noncaching. There
was something wrong with the caching of document function in XSL's...
It's not really "wrong" as such... it just doesn't work, because
document() "flies under the radar" of the Cocoon caching system.
That is, it creates a dependency of one resource upon of which
there's no way Cocoon can be aware, so there's no way for cocoon to
know when to invalidate the cache.
I'm not sure about whether Cocoon can't be aware of them. As far as I
know, Cocoon provides the UriResolver component and can therefore know
what is being accessed and when...
Good point! :-) So, maybe it is a straight-up BUG after all :-)...
Well, whilst Cocoon provides a URIResolver, that will only be invoked at
runtime. And the whole point of caching is to prevent the runtime stage.
Given the contents of a document() function can be dynamic, i.e. could
change between requests, there is no way for Cocoon to know which
documents are actually going to be referenced, and thus need to be cached.
Maybe a workaround might be to provide a list of documents to the
TraxTransformer from the sitemap, purely for caching:
<map:transform type="xslt" src="stylesheet-using-document-function.xsl">
<map:parameter name="referenced-documents"
value="xml/my-file{1}.xml xml/my-other-file{2}.xml"/>
</map:transform>
But then you get into hassles about where the filename is relative to,
as here it is referenced as a string, not as a source.
So, it really isn't that straightforward :-(
Regards, Upayavira
Hence, from Cocoon's perspective,
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
