cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ard Schrijvers" <a.schrijv...@hippo.nl>
Subject RE: XSL transrormers with use-request-parameters and caching [was: sitemap chaining]
Date Mon, 07 Aug 2006 08:28:24 GMT
</snip>

> 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.)

I think you do indeed miss one important point: Caching is only useful when retrieving the
cachekeys + checking wether the cached responses belonging to this cachekeys is cheap (fast).
Therefor, in the setup of components like generators and transformers, the cachekey is constructed
(or when it is a very simple one, like the FileGenerator, the key simple equals, this.inputSource.getURI()).
But, for example, for the TraxTransformer, the key is constructed depending on <use-request-parameters>
is true wether or not (of course one of the things it depends on). This is known during setup,
wether it should include all request-parameters, or only the one from the sitemap. For the
retrieval of the cachekey, it is NO option to parse the xsl for xsl:param's or whatever. Furthermore,
if you have a cachekey + valid cached response, you don't need the xsl at all. For this reason
it really not an option have parameters included in the cache key depending on wether they
are used in the xsl. 

You would most probably also run into difficulties because of the xsl:import's and xsl:include's,
where the parameters might be. I think everybody would be most happy if you could fix something
else if you want to jump into some code:

If I use the TraxTransformer, with <check-includes>true</check-includes>, and
I call an xsl "a" from the sitemap, and this xsl imports xsl "b", and "b" imports "c" (which
is very common in our projects, where "c" might be a std.xsl, and "b" a frame.xsl, and "a"
a page specific xsl), then, when you change "c", you still have to touch "b" to see the changes
on the site. In other words, the compiled xsl only checks the validities of included/imported
xsls for 1 level deep, not for two. It is a problem in excalibur xmlutil (where you needed
to be for the include parameters in cachekey anyway) :-) 

It might though be quite hard, but lots of people would be very happy..

Regards Ard


 

> 
> 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
> 
> 

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


Mime
View raw message