cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: [c2] stylesheet and logicsheet parameters
Date Mon, 16 Apr 2001 12:48:40 GMT


On Mon, 16 Apr 2001, Berin Loritsch wrote:

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

Good point. I was thinking in exactly the same tracks. I'm +1024 leaving
the TraxTransformer as simple as it can be and have the best benefit
from the caching system that way.

Giacomo

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


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message