Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3ADAE99F.76D05D48@apache.org>
Date: Mon, 16 Apr 2001 08:46:23 -0400
From: Berin Loritsch <bloritsch@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [c2] stylesheet and logicsheet parameters
References: <Pine.LNX.4.30.0104151557300.24217-100000@localhost.localdomain>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.

C2 has no DOM to pass.  It is all SAX events.  This solution can't work in
that environment.

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

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

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

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.

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

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


> and then you can access it from your xslt stylesheet that way instead of
> using $cookie/foo. the two approaches are functionally identical, right?
> 
> - donald
> 
> ---------------------------------------------------------------------
> 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