cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: [c2] stylesheet and logicsheet parameters
Date Sun, 15 Apr 2001 13:25:44 GMT

On Sat, 14 Apr 2001, Donald Ball wrote:

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

Thanks, Donald, to pointing us to it. Also for me some changes are
thrown in too quickly.

I personally don't like the browser capability stuff
in the TraxTransformer. We've already made some BrowserSelector where
such stuff belongs to and not into a Transformer. Look at this: as more
you put into the TraxTransformer the fewer is the chance you can cache
it because parametrisation of a Transformer is not very flexible (you
cannot say it what variables are really important for your stylesheet
and which ones are not).

The fact is that for every parameter/attribute/coockie/... you make
available in the stylesheet you have to take that variable into account
for the key generation steps for the cache system and thus you are
unlikely to have pages that will cache because of too many variables to
take into account (which likely changes your keys for every request). I
cannot think of a page in my systems that are designed to have the need
for variable values passed by C2 to my stylesheets.

> there
> are a few categories of data that people like to access from their
> stylesheets:

Really? From their stylesheets? Why?

> * request parameters
> * cookie values
> * session values
> * http headers
> * browser capabilities

Don't do it, guys. You ruin the cache system if you put all that into
the TraxTransformer.

I can understand if you need those values in XSP pages but I don't see
it in a Transformer.

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

I'm still playing devil's advocate and say that we don't need *any*
values from the environment in a stylesheet/TraxTransformer (I know this
might not be true but I'd really like to find the ones we really need
and not getting into FS for that). I am against it because the cache
system will get usesless if we negligent put variable stuff into the


To unsubscribe, e-mail:
For additional commands, email:

View raw message