cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: [c2] stylesheet and logicsheet parameters
Date Sun, 15 Apr 2001 21:04:44 GMT

On Sun, 15 Apr 2001, Donald Ball wrote:

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

> (note i think we've still got one big problem left in our cache system -
> how do xsp pages report upon which parameters they depend?)

As I've seen in the implementation this can be easily addressed,
Carsten, what do you think?

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

Ok, so that transformation depends on "everything" and thus cannot be cached,

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

> 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

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.



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

View raw message