cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [c2] stylesheet and logicsheet parameters
Date Tue, 17 Apr 2001 10:16:12 GMT

Berin Loritsch a écrit :
> > > 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
> > > > 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 -

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

View raw message