You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2001/04/14 23:01:32 UTC
[c2] stylesheet and logicsheet parameters
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. there
are a few categories of data that people like to access from their
stylesheets:
* request parameters
* cookie values
* session values
* http headers
* browser capabilities
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?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] stylesheet and logicsheet parameters
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 3:49 PM +0200 15/4/01, giacomo wrote:
>> Is it worth providing the Context Params too?
>
>Yes, put everything into the stylesheet so it will never be able to be
>cached, right?
>
>Giacomo
I see your point Giacomo.
I am thinking in terms of my current project that is all.
I remember, you complained to me before, only thinking in terms of
implementation, not architecture ;)
I am thinking about an application where caching is useless because
everyone has a custom view of dynamically changing distributed data and
everyone needs to see the changes made by anyone else, as soon as possible,
because they are trading with each other via the system in real-time.
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] stylesheet and logicsheet parameters
Posted by giacomo <gi...@apache.org>.
On Sun, 15 Apr 2001, Jeremy Quinn wrote:
> At 5:01 PM -0400 14/4/01, Donald Ball wrote:
> >there
> >are a few categories of data that people like to access from their
> >stylesheets:
> >
> >* request parameters
> >* cookie values
> >* session values
> >* http headers
> >* browser capabilities
>
> Yummy, yes please!
>
> Is it worth providing the Context Params too?
Yes, put everything into the stylesheet so it will never be able to be
cached, right?
Giacomo
>
> [snip]
>
> >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).
>
> I like #2
>
>
> regards Jeremy
> --
> ___________________________________________________________________
>
> Jeremy Quinn Karma Divers
> webSpace Design
> HyperMedia Research Centre
>
> <ma...@mac.com> <http://www.media.demon.co.uk>
> <phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
>
> ---------------------------------------------------------------------
> 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
Re: [c2] stylesheet and logicsheet parameters
Posted by Jeremy Quinn <je...@media.demon.co.uk>.
At 5:01 PM -0400 14/4/01, Donald Ball wrote:
>there
>are a few categories of data that people like to access from their
>stylesheets:
>
>* request parameters
>* cookie values
>* session values
>* http headers
>* browser capabilities
Yummy, yes please!
Is it worth providing the Context Params too?
[snip]
>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).
I like #2
regards Jeremy
--
___________________________________________________________________
Jeremy Quinn Karma Divers
webSpace Design
HyperMedia Research Centre
<ma...@mac.com> <http://www.media.demon.co.uk>
<phone:+44.[0].20.7737.6831> <pa...@sms.genie.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] stylesheet and logicsheet parameters
Posted by Colin Britton <cb...@centervilletech.com>.
Having been one of the ones that started this I guess it would be worth me
throwing in my two cents.
I am interested in being able to better control activity inside the
stylesheet based on a combination of persistant, session and request
information about the user/device that is making the request. I disagree
with the opinion that this information should come in just through XSP, and
therefore in the content stream. for a number of reasons.
1) generated content does not have to always be tied to the
user/request/device and therefore should not be forced to contain
non-content information just to pass request information into the
stylesheet. There is also a cache opporunity here.
2) With content aggregation we are going to need many facilites to best
display an aggregate set of information, XSLT is a powerful engine to
manipulate this information, but it requires additional real-time
information to best server the content.
I like donalds second idea where the key objects we need to get to are
passed into any XSLT process as a dom object. This is particually usefull
for places where multiple values could exist for an item (cookies for
instance).
rgds
CB
----- Original Message -----
From: "Donald Ball" <ba...@webslingerZ.com>
To: <co...@xml.apache.org>
Sent: Saturday, April 14, 2001 5:01 PM
Subject: [c2] stylesheet and logicsheet parameters
> 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. there
> are a few categories of data that people like to access from their
> stylesheets:
>
> * request parameters
> * cookie values
> * session values
> * http headers
> * browser capabilities
>
> 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?
>
> - 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
Re: [c2] stylesheet and logicsheet parameters
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Berin Loritsch a écrit :
>
<snip/>
>
> > > 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.
>
> Can you give me an example?
Just look at the slides examples in C2 : there's only 2 stylesheets, and
navigation is implemented using request parametres that are mapped to
stylesheet parameters.
I also used this feature to build very easily a small app for presenting
industrial automation block-diagrams (defined in an XML file) on the Web
: 2 stylesheets generate a HTML page and a SVG diagram respectively.
Several request/stylesheet parameters allow to define the selected block
(highlighted in the SVG, details in the HTML) and drawing options (zoom
level, text size, grid...)
>
> > > > 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.
Not sure XSP is the good solution : both in the slide example and in my
block-diagram application, content is generated with a FileGenerator
from a XML file, and using XSP will lead to a unneeded complexity (e.g
read the external file and aggregate it with request parameters).
> >
> > 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.
>
> If you have a solution where you have very different results based on the
> parameter, then I can see having a few different stylesheets and make the
> choose between them in the sitemap.
>
> For instance, I have a situation where I have a specific set of documents
> that, depending on the user's role, need to be rendered differently. If
> the role allows the user to edit the document, it is represented as a form,
> if the role allows the user to comment on the document, the comment section
> is added, etc. There is a set of four very different transformations that
> need to be accomplished. My solution is to create four different stylesheets
> and choose between them in the sitemap.
>
> It is very effective. Any simple display oriented changes (such as displaying
> the user name and associated company) is done comfortably in XSP.
>
> If it is unnacceptable to do a simple ParameterizedTransformer in a separate
> stage, then I would like to see a ParameterizedTraxTransformer separate and
> distinct from the regular TraxTransformer.
>
> > > 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.
>
> Not necessarily. Besides, if that component is already included, they don't
> have to write it. As it stands Cocoon is very flexible, and there is very
> little that developers have to write outside of what is already available.
>
> > 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.
>
> Understandable. I am thick headed. Please, in your arguments, present
> real world problems and think of how it would be best solved. This goes
> a long way in convincing me, and others. The pure hypothetical approach
> leaves ambiguities that you may consider common knowledge but others
> won't be able to fill in the holes. That is just my experience with
> expressing ideas and proposals to other developers.
>
> I would like to hear your thoughts on potential problem areas of Cocoon 2.
> It is getting ready to be used in the real world, and by my informal testing
> scales better than Cocoon 1. Cocoon 2 offers more in maneagability and
> realizing web applications than Cocoon 1 does (IMO). For users of Cocoon 1,
> Cocoon 2 will make some things much easier, and some things harder. For
> new users, hopefully they will see the benefit of some of the decisions
> made in Cocoon 2.
>
I like the idea of the ParameterTransformer : it could add these
"/meta/..." elements before the XSL transformation stage, and could also
be configured with the actual parameter used.
Regarding cache, this would allow to define caching policy at this level
: depending on the application, we might consider that every variant
should be cached, while in other situations we might consider that every
variant should be regenerated. And if the ParameterTransformer knows
about the required parameters, defining the cache validity is easy.
My .02 euro...
--
Sylvain Wallez
Anyware Technologies - http://www.anyware-tech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] stylesheet and logicsheet parameters
Posted by Berin Loritsch <bl...@apache.org>.
Donald Ball wrote:
>
> 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.
Maybe so, but performance of DOM with Xalan is not near as good as with
SAX. I like the cleanness of the pure SAX approach whenever possible.
> > > > > 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 am trying to say that it lends to a cleaner API and approach if we look
at the problem from a different viewpoint. If you try to overload ideas
such as a TraxTransformer with Cocoon proprietary extensions, it leads
to less portability. That means that people who want to migrate to or from
proprietary solutions have more work if they want to take advantage of
those features.
I am not _forbidding_ the use of parameters in the transformation stage,
but trying to incorporate a more focused way of doing that. In Cocoon2,
it is nothing to add another Transformer (in this case a lightweight one),
to do the setting up that you need.
> > 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.
Can you give me an example?
> > > 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.
If you have a solution where you have very different results based on the
parameter, then I can see having a few different stylesheets and make the
choose between them in the sitemap.
For instance, I have a situation where I have a specific set of documents
that, depending on the user's role, need to be rendered differently. If
the role allows the user to edit the document, it is represented as a form,
if the role allows the user to comment on the document, the comment section
is added, etc. There is a set of four very different transformations that
need to be accomplished. My solution is to create four different stylesheets
and choose between them in the sitemap.
It is very effective. Any simple display oriented changes (such as displaying
the user name and associated company) is done comfortably in XSP.
If it is unnacceptable to do a simple ParameterizedTransformer in a separate
stage, then I would like to see a ParameterizedTraxTransformer separate and
distinct from the regular TraxTransformer.
> > 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.
Not necessarily. Besides, if that component is already included, they don't
have to write it. As it stands Cocoon is very flexible, and there is very
little that developers have to write outside of what is already available.
> 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.
Understandable. I am thick headed. Please, in your arguments, present
real world problems and think of how it would be best solved. This goes
a long way in convincing me, and others. The pure hypothetical approach
leaves ambiguities that you may consider common knowledge but others
won't be able to fill in the holes. That is just my experience with
expressing ideas and proposals to other developers.
I would like to hear your thoughts on potential problem areas of Cocoon 2.
It is getting ready to be used in the real world, and by my informal testing
scales better than Cocoon 1. Cocoon 2 offers more in maneagability and
realizing web applications than Cocoon 1 does (IMO). For users of Cocoon 1,
Cocoon 2 will make some things much easier, and some things harder. For
new users, hopefully they will see the benefit of some of the decisions
made in Cocoon 2.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] stylesheet and logicsheet parameters
Posted by Donald Ball <ba...@webslingerZ.com>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] stylesheet and logicsheet parameters
Posted by Berin Loritsch <bl...@apache.org>.
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
Re: [c2] stylesheet and logicsheet parameters
Posted by Berin Loritsch <bl...@apache.org>.
Donald Ball wrote:
>
> On Sun, 15 Apr 2001, giacomo wrote:
>
> > 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.
Ok. So you are saying that if cookie "foo" has 10 different values and
request parameter "bar" can have 100 different values, then we will have
1000 different cache entries for this one (1) stylesheet. It also means
that we have n/1000 (where n is the number of already cached entries) chance
of hitting the cache. We also have (1000-n)/1000 chance of missing the
cache.
Hmmm. Now lets throw in request parameter "foobar" that can have an
undefined or infinite number of values. At this point, cache is pointless,
and we have allowed this to happen if we parameterize the transformer.
We can draw another real world example:
We want to alter our transformation based on country and province/state
(assuming all countries have an equivalent). So there are >=130 country
codes, US has 50 states and ~3 "territories" (Guam, Puerto Rico, etc),
Canada has ~5 provinces. If these are kept in two different variables,
then we will have (with just US and Canada defined) 130 * 58 entries.
That's 7,540 entries for one stylesheet. We will have over 10,000 entries
by the time we are done. The cache will grow to such a size that it will
be cheaper and more scalable just to freshly generate the page every time.
Let's put that in a pooled environment like the announcement made earlier
and you have two machines with four instances of Tomcat running. On each
machine you would have to have over 40,000 entries for the one stylesheet.
Can you imagine the overhead in RAM?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] stylesheet and logicsheet parameters
Posted by Donald Ball <ba...@webslingerZ.com>.
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
> XSLT.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] stylesheet and logicsheet parameters
Posted by giacomo <gi...@apache.org>.
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,
right?
> > > * 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
XSLT.
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.
Giacomo
:)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] stylesheet and logicsheet parameters
Posted by Donald Ball <ba...@webslingerZ.com>.
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.
(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?)
> > 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.
> > * 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.
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?
- donald
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [c2] stylesheet and logicsheet parameters
Posted by Davanum Srinivas <di...@yahoo.com>.
Another option (instead of passing params into TraxTransformer) is to use cookie.xsl, request.xsl,
response.xsl and session.xsl depending on what you need.
> > 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
=====
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
Re: [c2] stylesheet and logicsheet parameters
Posted by giacomo <gi...@apache.org>.
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 <gi...@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
Re: [c2] stylesheet and logicsheet parameters
Posted by Berin Loritsch <bl...@apache.org>.
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...
> 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 <gi...@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
Re: [c2] stylesheet and logicsheet parameters
Posted by Davanum Srinivas <di...@yahoo.com>.
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.
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.
Thanks,
dims
--- giacomo <gi...@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
Re: [c2] stylesheet and logicsheet parameters
Posted by giacomo <gi...@apache.org>.
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