cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: [c2] stylesheet parameters redux, call for vote
Date Wed, 18 Apr 2001 10:31:27 GMT
giacomo wrote:

> 
> On Tue, 17 Apr 2001, Donald Ball wrote:
> 
> 
>> so i think these are the options available to us for accessing
>> request-time parameters in our stylesheets:
>> 
>> 1. have the trax transformer pass in all possible parameters individually.
>> a request parameter named 'foo' would be accessible via:
>> 
>> <xsl:param name="request--foo"/>
>> <xsl:value-of select="$request--foo"/>
>> 
>> 2. have the trax transformer pass in all possible parameters via DOM
>> objects:
>> 
>> <xsl:param name="request"/>
>> <xsl:value-of select="$request/foo"/>
>> 
>> 3. have a parameter transformer add the parameters and their values to an
>> element underneath the root element:
>> 
>> <xsl:value-of select="/meta/request/foo"/>
>> 
>> (with namespaces, naturally)
>> 
>> i reckon the sitemap might look like:
>> 
>> <map:transform type="parameter">
>>   <parameter name="request-parameters" value="foo,bar"/>
>>   <parameter name="cookies" value="*"/>
>> </map:transform>
>> 
>> 4. do nothing, force authors to add request-time parameters to their xml
>> stream using xsp or their own custom sitemap component.
>> 
>> i reckon, after careful consideration, that (3) is probably the best
>> solution, but (2) still has a lot to recommend it. i think they have the
>> practically the same effect on the cache engine since both can report with
>> precision which request-time parameters are relevant to their
>> cacheability. what do y'all think?
> 
> 
> Well, its ok for me. I still don't see how a trax transformer knows
> which parameters will be used by the stylesheet? But I hope you can
> enlight me :)
> 

In (2), the DOM "proxy" can know *a posteriori*. Is it really needed to 
know in advance?

I mean, after the first request has been processed, the engine knows 
which parameters the output depends on (the ones requested to the DOM). 
Thus the cache key will depend on the parameters really used.

When a second requests comes, if the parameters actually used have the 
same values, the cached result can be delivered. Else, a new key is 
re-computed and we have a new result for caching.

Note that, depending on execution paths, some requests can have more 
parameters actually used than others, but the set should be predictive. 
For instance, if $request/cookies/foo is not null, $session/locale can 
be used, while if cookies/foo is null, no locale is used.

I don't know (yet) the details of the caching algorithm, but it should 
work, assuming no "extra" or "random" dependencies affect the 
transformation.


Thoughts? Am I completely stray?


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


Mime
View raw message