cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin Britton" <cbrit...@centervilletech.com>
Subject Re: [c2] stylesheet and logicsheet parameters
Date Sat, 14 Apr 2001 22:51:50 GMT
Having been one of the ones that started this I guess it would be worth me
throwing in my two cents.

I am interested in being able to better control activity inside the
stylesheet based on a combination of persistant, session and request
information about the user/device that is making the request. I disagree
with the opinion that this information should come in just through XSP, and
therefore in the content stream. for a number of reasons.

1) generated content does not have to always be tied to the
user/request/device and therefore should not be forced to contain
non-content information just to pass request information into the
stylesheet. There is also a cache opporunity here.

2) With content aggregation we are going to need many facilites to best
display an aggregate set of information, XSLT is a powerful engine to
manipulate this information, but it requires additional real-time
information to best server the content.

I like donalds second idea where the key objects we need to get to are
passed into any XSLT process as a dom object. This is particually usefull
for places where multiple values could exist for an item (cookies for
instance).

rgds
CB

----- Original Message -----
From: "Donald Ball" <balld@webslingerZ.com>
To: <cocoon-dev@xml.apache.org>
Sent: Saturday, April 14, 2001 5:01 PM
Subject: [c2] stylesheet and logicsheet parameters


> we've seen a sudden proliferation of parameters being passed into the c2
> stylesheets (and logicsheets?) over the past few days. before this gets
> out of hand, i think we should step back for a moment and come up with
> ground rules for how to segment the parameter namespace, as it were. there
> are a few categories of data that people like to access from their
> stylesheets:
>
> * request parameters
> * cookie values
> * session values
> * http headers
> * browser capabilities
>
> in c1, the request parameters (those whose names were were valid qnames,
> anyway) were passed in without qualification, while the cookie and session
> variables were passed in prefixed by C_ and S_, respectively. http headers
> were unavailable, while browser capabilties were passed in as a DOM object
> (if you applied ovidiu's patch) and accessible something like this:
>
> $ua_capabilities/some_param
>
> (i think anyway - i never used it for real myself - correct me if wrong).
>
> as i see it, there are basically a couple of different options available
> to us for c2:
>
> 1. pass in all of the interesting parameters individually, and prefix them
> using something namespace-like (e.g. request:foo, cookie:bar).
>
> 2. create DOM objects for each of the broad categories and pass them in as
> distinct objects. (e.g. $request/foo, $cookie/bar).
>
> the advantage of the first approach is that it's simple and
> straightforward. the disadvantages are that stylesheet authors must
> declare all of their parameters individually, and that it's time-consuming
> to iterate over all of the request-time variables and set them as
> stylesheet parameters - especially since the author is only interested in
> a few. this could be mitigated if the trax processor was able to tell us
> what parameters the stylesheet is expecting - i wonder if that's possible?
>
> one advantage of the second approach is that the stylesheet authors need
> not declare each parameter they want to inspect, just the broad
> categories. a possible disadvantage is that we must construct a
> heavyweight DOM object for each category, but we could turn this into an
> advantage - we could create our own DOM objects that would call back the
> proper functions on the request object. that is to say, evaluating
> $request/foo would result in invoking request.getParameter("foo") - but
> that method invokation wouldn't occur unless it was needed.
>
> thoughts?
>
> - 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


Mime
View raw message