cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [c2] stylesheet and logicsheet parameters
Date Mon, 16 Apr 2001 12:35:17 GMT
Davanum Srinivas wrote:
> 
> Giacomo,
> 
> Commented out the parameters passed into the C2 Stylesheets for now. We can switch back
on after
> 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.

The Browser stuff IMNSHO should be part of a distinct ParameterTransformer.  That way, when
they
are needed by someone at transformation level or beyond, they can have it.  In fact, the
ParameterTransformer would be best used as the last stage.

The TraxTransformer should be just a TraxTransformer, and nothing else.  When you need a different
distinct ability, then create the tool for that purpose--but don't alter another tool completely.
That is why we have a Component based approach.  It allows us to have several small/lightweight
components as opposed to a few huge ones.  The benefits of this approach is that the people
who
need parameterization after the generator (sometimes it doesn't make sense to use XSP for
the
value of one session variable) can have it, but the people who don't want it won't have to
suffer
the negative affects of having it.  If only certain OS vendors really used this approach...

> Irrespective of whether we pass params into TraxTransformer, I definitely think we need
the new
> 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
> opinion.

I agree with this last statement.  I just think that we shouldn't pass the params into TraxTransformer.
It should be a separate and distinct ParameterTransformer.

> 
> Thanks,
> dims
> 
> --- giacomo <giacomo@apache.org> 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: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> 
> =====
> Davanum Srinivas, JNI-FAQ Manager
> http://www.jGuru.com/faq/JNI
> 
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
> 
> ---------------------------------------------------------------------
> 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