cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [c2] stylesheet and logicsheet parameters
Date Mon, 16 Apr 2001 17:31:11 GMT
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


Mime
View raw message