You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Mark Lundquist <ml...@wrinkledog.com> on 2005/06/18 06:04:45 UTC
Sitemap globals in XSLT?
Hi,
Anybody know a way to access sitemap globals from within a stylesheet?
(That is, w/o passing them in as stylesheet parameters). I'm using
Saxon. Any ideas welcome! :-)
thx,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap globals in XSLT?
Posted by Geert Josten <Ge...@daidalos.nl>.
>> Would using a non-caching pipe 'help' in this case?
>
> Yes, it would solve that problem, if potentially causing a performance
> problem at the same time.
That is why i quoted the word help..
:-D
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap globals in XSLT?
Posted by Upayavira <uv...@odoko.co.uk>.
Geert Josten wrote:
>> 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 :-(
>
>
> Ah, that makes sense and nope, it isn't. I guess that is why include
> transformers are adviced over the document() function.
>
> Would using a non-caching pipe 'help' in this case?
Yes, it would solve that problem, if potentially causing a performance
problem at the same time.
Upayavira
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap globals in XSLT?
Posted by Geert Josten <Ge...@daidalos.nl>.
> 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 :-(
Ah, that makes sense and nope, it isn't. I guess that is why include transformers are adviced over
the document() function.
Would using a non-caching pipe 'help' in this case?
Cheers,
Geert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap globals in XSLT?
Posted by Upayavira <uv...@odoko.co.uk>.
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: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap globals in XSLT?
Posted by Mark Lundquist <ml...@wrinkledog.com>.
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 :-)...
Cheers,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap globals in XSLT?
Posted by Geert Josten <Ge...@daidalos.nl>.
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. :)
>> 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...
> However, with globals it shouldn't even matter, since those aren't going
> to change :-)
Err.. Depends on whether you allow sitemaps to be changed and reloaded... :-P
During development at least..
Cheers,
G.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap globals in XSLT?
Posted by Mark Lundquist <ml...@wrinkledog.com>.
On Jun 18, 2005, at 1:04 AM, Geert Josten wrote:
>
>> Hi,
>> Anybody know a way to access sitemap globals from within a
>> stylesheet? (That is, w/o passing them in as stylesheet parameters).
>> I'm using Saxon. Any ideas welcome! :-)
>> thx,
>> —ml—
>
> I replied earlier that I used the RequestGenerator to get parameters
> into the stream. Doing so, you can pass a pipe uri to the stylesheets
> that refers to that generator. Just use the document() function inside
> the stylesheet, to access the pipe and you will have the parameters
> available as XML tree...
>
> :-)
>
Hi Geert,
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?
> 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.
However, with globals it shouldn't even matter, since those aren't
going to change :-)
Cheers,
—ml—
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Sitemap globals in XSLT?
Posted by Geert Josten <Ge...@daidalos.nl>.
> Hi,
>
> Anybody know a way to access sitemap globals from within a stylesheet?
> (That is, w/o passing them in as stylesheet parameters). I'm using
> Saxon. Any ideas welcome! :-)
>
> thx,
> —ml—
I replied earlier that I used the RequestGenerator to get parameters into the stream. Doing so, you
can pass a pipe uri to the stylesheets that refers to that generator. Just use the document()
function inside the stylesheet, to access the pipe and you will have the parameters available as XML
tree...
:-)
By the way, make sure that the parameters pipe is noncaching. There was something wrong with the
caching of document function in XSL's...
HTH,
Geert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org