cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject [c2] stylesheet and logicsheet parameters
Date Sat, 14 Apr 2001 21:01:32 GMT
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

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


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


- donald

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

View raw message