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 Sun, 15 Apr 2001 21:38:02 GMT
On Sun, 15 Apr 2001, giacomo 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.
> Normally the TraxTransformer is asked to generate a key and a Validity
> object *before* it processes its stylesheet. This, in terms of caching,
> would result in saying that potentially *all* parameter/coockies/session
> or whatever you'd like a stylesheet will have access to have to be taken
> into consideration.

well, that's an implementation detail (generating the key before or after
the stylesheet is processed) that could be changed.

> > uh, to affect the transformation based on request-time data, naturally.
> Ok, so that transformation depends on "everything" and thus cannot be cached,
> right?

no, the transformation depends on a discrete set of request-time
parameters which can be enumerated and combined into a cache key.

> > > Don't do it, guys. You ruin the cache system if you put all that into
> > > the TraxTransformer.
> >
> > you don't ruin it, you just make the cache bigger. but since you can find
> > out which parameters the stylesheet depends on by inspection, you can
> > limit the size of the cache.
> How would you do that, I don't see it?

if my stylesheet depends on the value of a cookie named 'foo' (which can
have 'x' different values, say) and the value of a request parameter named
'bar' (which can have 'y' different values), then the cache for this
component is increased by, at most, x*y.

> > 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']
> >
> > and then you can access it from your xslt stylesheet that way instead of
> > using $cookie/foo. the two approaches are functionally identical, right?
> Functional they might be identicall but semantically they differ.
> Generating content is one step and transforming is another. But you'd
> like to generate additional content by a XSLT transformer which is IMHO
> wrong. You can do that by a XIncludetransformer, that's ok for me bt not

the former requires the user to manually add the parameters they're
interested in. the latter doesn't. i tend to lean towards the solution
that makes life easier on users. :)

> Also programmatically they differ because the xsp page can exactly tell
> the cache system what it depends on but not the TraxTransformer. The
> Transformer can only say that it depends on all input value that a
> stylesheet potentially can access. And because of this I'd like more to
> specify exactly what my content depends on in a xsp page that let a
> Transformer decide which cannot tell exactly.

well first of all, i haven't seen a way described yet for an xsp page to
tell the cache system what parameters it depends on. i assume you have a
plan to address that though. anyway, the solution i'm trying to describe
would give the TraxTransformer a way to tell the cache system what
parameters it depends on. by constructing our own special DOM objects that
track which parameters the xslt stylesheet accesses, we can tell with
precision which parameters we should use to construct the cache key.

or we could simply say that if you write a stylesheet which accesses
request-time data through the special parameter objects, its results are
uncacheable. thus we leave that choice to the developer rather than
deciding for him.

- donald

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

View raw message