You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by "spam2006@meeque.de" <sp...@meeque.de> on 2006/08/04 15:39:54 UTC

XSL transrormers with use-request-parameters and caching [was: sitemap chaining]

Hi Folks!

I'm not too familiar with cocoon any more, since I haven't been using it
for a while. (Still one of my favorite projects though!) I'm also not an
expert on caching in cocoon, but I wonder if the following problem
couldn't be overcome technically:

Ard Schrijvers wrote:
> I am becoming a little evangelistic here about the
> <use-request-parameters>true</use-request-parameters> in the
> components declaration, but never never never ever ever ever use
> <use-request-parameters>true</use-request-parameters>: set it to
> FALSE !!!
> 
> [...]
> 
> If a crawler comes by with /foo/bar?tfwewq=21r123rwedewqf and the
> tfwewq=21r123rwedewqf is added by the crawler, and you use
> <use-request-parameters>true</use-request-parameters>, you will end
> up with cache entries containing tfwewq=21r123rwedewqf

So the problem here is, that all parameters in the request are used for
caching. However, only those parameters used in the XSL stylesheet could
possibly change the outcome of the transformation. As far as I know,
these are exactly the parameters, which are declared as global
parameters in the stylesheet.

Even though I don't know which components play together when building
and accessing caches, that should be limited to parameters really used
in the stylesheet. I mean, the components responsible for caching have
to check for changes of the stylesheet anyway. (Probably just by
timestamp?) So anytime the stylesheet changed, they could have a look at
it, and find out which parameters are actually relevant for caching.
This might slow down the first use of a stylesheet quite a lot, but it
should fix the above caching issues.

I haven't looked at the details yet. But I think an implementation of
the above shouldn't be too hard. Or am I missing something? Anyway, if
you think it might be useful, I could investigate the topic further.
(But I don't know how much time I can spend on that right now.)

On the other hand, even today, one can use the use-request-parameters
stuff for development. That's useful, because stylesheet parameters may
change frequently while work is being done on them. However, for
productive use I can only second what Ard said. At least for now.

Regards,
Michael

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


Re: XSL transrormers with use-request-parameters and caching [was: sitemap chaining]

Posted by Joerg Heinicke <jo...@gmx.de>.
On 04.08.2006 09:39, spam2006@meeque.de wrote:

> So the problem here is, that all parameters in the request are used for
> caching. However, only those parameters used in the XSL stylesheet could
> possibly change the outcome of the transformation. As far as I know,
> these are exactly the parameters, which are declared as global
> parameters in the stylesheet.
> 
> Even though I don't know which components play together when building
> and accessing caches, that should be limited to parameters really used
> in the stylesheet. I mean, the components responsible for caching have
> to check for changes of the stylesheet anyway. (Probably just by
> timestamp?) So anytime the stylesheet changed, they could have a look at
> it, and find out which parameters are actually relevant for caching.
> This might slow down the first use of a stylesheet quite a lot, but it
> should fix the above caching issues.

That would be absolutely hard-core. You would need to re-implement half 
an XSLT processor since there can be imports and includes. The interface 
to the XSLT processor is used for setting the parameters. That's the 
interface Cocoon is aware of and can grab the parameters easily used for 
caching.

Joerg

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