cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <>
Subject Re: [c2] stylesheet and logicsheet parameters
Date Sun, 15 Apr 2001 16:45:46 GMT

Commented out the parameters passed into the C2 Stylesheets for now. We can switch back on
we decide on the following:
- Which parameters are absolutely needed.
- What are the names of the parameters
- What are the values that we should send in.

Irrespective of whether we pass params into TraxTransformer, I definitely think we need the
Browser component, so that people who write custom code can re-use it from anywhere
(Generator/Transformer/Formatter). The BrowserSelector too can make use of this component
in my


--- giacomo <> wrote:
> 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
> TraxTransformer/stylesheet.
> Giacomo
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

Davanum Srinivas, JNI-FAQ Manager

Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.

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

View raw message