[c2] stylesheet parameters redux, call for vote

[Donald Ball <ba...@webslingerZ.com>]

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?

- donald


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

Re: [c2] stylesheet parameters redux, call for vote

[Paul Russell <pr...@apache.org>]

* Donald Ball (balld@webslingerZ.com) wrote :
> i reckon the sitemap might look like:
> 
> <map:transform type="parameter">
>   <parameter name="request-parameters" value="foo,bar"/>
>   <parameter name="cookies" value="*"/>
> </map:transform>
[...]
> 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?

Either 2 or 3 is fine by me, providing that we can tell which parameters
are affecting the cachability of the request. (which requires them to be
specified in the sitemap, right?)


Paul

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

Re: [c2] stylesheet parameters redux, call for vote

[Santiago Gala <sg...@hisitech.com>]

Colin Britton wrote:

>>  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?
>> 
> 
> I don't have a vote but since I started this whole thread I guess my input
> might count for something ;-)
> 
> I think (3) or (2) will get me where I want to go, *but* since I believe
> they both have the same issues for the cache engine I prefer using (2)  the
> params method of the stylesheet. With the support for default params in most
> of the XSLT editors (Like eXcelon Stylus) this fits into a broader use
> pattern in the XSL community, I have now also seen a number of other XSLT
> examples use this method (not that this is ever a great reason to do
> something).

(I don't have a vote, just commenting)

The (2) solution has a very appealing concept: it is 100% compatible 
with the "pull" approach used in Turbine for templating. This means that 
some (bean-like) objects are "pulled" into the template-writer workspace 
and then the template writer is able to use them at will in templates.

The syntax under velocity would be like $request.headers.accept, quite 
similar to what you are doing here ($request/headers/accept).

This will allows for a smooth transition between other templating 
solutions and C2 (just expose the "toolbox objects" as DOM, and pass 
them down the pipeline). The language impedance mismatch would be minimized.



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

Re: [c2] stylesheet parameters redux, call for vote

[Colin Britton <cb...@centervilletech.com>]

>  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?
>
I don't have a vote but since I started this whole thread I guess my input
might count for something ;-)

I think (3) or (2) will get me where I want to go, *but* since I believe
they both have the same issues for the cache engine I prefer using (2)  the
params method of the stylesheet. With the support for default params in most
of the XSLT editors (Like eXcelon Stylus) this fits into a broader use
pattern in the XSL community, I have now also seen a number of other XSLT
examples use this method (not that this is ever a great reason to do
something).

I think adding any metadata (request parameters/cookies/session info) into
the content stream confuses things - for the designers and scripters we want
to use and modify our apps with. First question is where do you embed it?
cannot be at the root? so as DB says you put it one element down - so then,
what about potential tag conflicts with content? so you say use a namespace,
well at this point I just think it gets worse, yeah all this stuff works but
it is confusing, I like $request/foo and using xpath, and the support my
wysiwyg tool gives me (and the designers etc)..... I however also agree with
the statement all along, parameters in transformations mess with caching,
agreed - that is part of the cost and one needs to be aware of it.

rgds
CB


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

Re: [c2] stylesheet parameters redux, call for vote

[Donald Ball <ba...@webslingerZ.com>]

On Wed, 18 Apr 2001, Santiago Gala wrote:

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

i think you got it completely. and stated it better than i have been
trying to do. :). carsten, would it be possible for this scheme to mesh
with the cache system?

- donald


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

Re: [c2] stylesheet parameters redux, call for vote

[Santiago Gala <sg...@hisitech.com>]

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

Re: [c2] stylesheet parameters redux, call for vote

[giacomo <gi...@apache.org>]

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

Giacomo

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


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