cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject Re: [c2] stylesheet and logicsheet parameters
Date Mon, 16 Apr 2001 16:23:50 GMT
On Mon, 16 Apr 2001, Berin Loritsch wrote:

> > > 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.
> >
> > okay, sure, that's definitely something that authors should be _aware_ of,
> > but i still think it's something we should allow. it's very easy for us to
> > tell which parameters a stylesheet depends upon if we pass in our own DOM
> > objects - whenever a parameter is accessed from the stylesheet, our DOM
> > object can record the access and when we're finished, we can query the DOM
> > object and find out upon what parameters the stylesheet depends.
> C2 has no DOM to pass.  It is all SAX events.  This solution can't work in
> that environment.

that's inane, it seems that you didn't read or try to understand what i
was suggesting. i was suggesting creating our own virtual DOM object to
pass into the TraX transformer which would issue callback to the c2
request objects whenever certain nodes were accessed on it. i can create a
DOM object by hand. it's not that hard. the solution _can_ work in this
environment, it's merely a question of if we want to use it or not.

> > > > there are a few categories of data that people like to access from
> > > > their stylesheets:
> > >
> > > Really? From their stylesheets? Why?
> >
> > uh, to affect the transformation based on request-time data, naturally.
> What's wrong with adding a few cues in the XML being passed to the
> transformer and then filtering them out?
> How much alteration of the Transformation is going to be done?  Wouldn't it
> be easier to choose between a few simpler stylesheets than have one very
> complex one?  That solves two problems: performance loss due to complexity
> of stylesheet, and performance loss due to missed cache hits.

in some cases, yes - but in other cases, maybe not.

> But what if I don't want to do it your way?  What if I want to do all my
> dynamic portions as a serverpage?  Do I have to suffer from missed cache
> hits because the transformer is thinking I need to pay attention to the
> Context, Request, Cookie, http headers, etc.?

you haven't been paying attention to my suggestion at all. but i'm shocked
that you'd complain that i'm limiting your choice. _you_ don't _have_ to
use parameters in your logicsheets if you don't want to - but you're
trying to forbid me from doing so.

> I personally would rather do my logic in the Generator, choose my
> transformers based on runtime parameters, but keep the transformers
> simple.  I can only see the headaches that debugging this type of FS
> can only create.  Cocoon is already complex enough for the newcomer to
> understand--by throwing all this other stuff in the pot, we will lose
> another two or three weeks.

and i can tell you that sometimes, a parameterized stylesheet is the
simplest solution.

> > look, the other option you could do is add the data you're interested in
> > to the xml page using xsp - e.g. add a cookie named 'foo' valued 'bar'
> > sort of like this:
> >
> > /meta/cookie[@foo='bar']
> I would rather see this approach than it done in the TraxTransformer.

but that's stupid - you're going to have to fork the pipeline on this
parameter, right? so it would make the most _sense_ to do the fork as far
towards the _end_ of the pipeline as _possible_, at least as far as the
cache engine is concerned.

> Or you can have your own ParameterTransformer that can be run anywhere in the
> pipeline.

forcing c2 developers to write custom java components for everything is
going to ensure that c2 remains a niche product.

look, i'm obviously a little steamed up about this; i'm going to take a
break, and then i'm going to split this up into a couple of threads - one
to argue the merits of parameterized stylesheets, and one to discuss the
problems i fear we're going to encounter when (and if) c2 starts being
used in the real world.

- donald

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

View raw message