cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: AW: [RT] sharing latest research production (long!)]
Date Mon, 19 Feb 2001 18:01:19 GMT
Paul Russell wrote:
> * Carsten Ziegeler ( wrote :
> > > <long snip>
> > > ..
> > > Stefano Mazzocchi wrote:
> > > > Giacomo Pati wrote
> > > > This assumption might be acceptable for an XSLT transformer but almost
> > > every
> > > > other specialized transformer can and will change over time
> > > (I18nTransformer,
> > > > SQLTransformer).
> > >
> > > Yes, this is why I suggest to place all these 'specialized'
> > > transformation capabilities at generation time.
> > >
> > Do you mean, not to have those transformers and instead have some corresponding
> > But that would reduce the transformation stage of the pipeline to pure stylesheet
> Not *all* translaters. I think stefano means to avoid situations where
> the transformation acts on commands contained within the content stream
> to retrieve content from elsewhere without using xinclude.

Yes, this is a good explaination.

The "external inclusion" is the key: a transformer that goes someplace
'outside cocoon' to grab content using the information that comes thru
the pipeline as SAX events is almost impossible to cache efficiently.

Why? because you'd have to pass the SAX events thru to let the
transformer tell you if the cached content is still valid or not.

The XIncludeFilter and the SQLTransformer do that.... but the
I18nTransformer does not (as far as I know, never looked into the code).

So, let me restate: if you write a transformer that 'goes outside' on a
location identified by SAX events coming in, then I suggest to turn it
into a generator.

Whick makes sense semantically: if fact you are not transforming
anything, but rather generating using XML configurations.

XInclude is the only exception to this rule and for this reason it will
implemented directly into the pipeline machinery so you get it for free
and don't have to care about xincluded fragment caching since the
sitemap will do that for you.

> I must admit,
> bits of this are slightly over my head -- I'm not entirely sure what
> Stefano means by atomic in this context, for example. Stefano, am I
> understanding you right?

Yes. 'Atomic' means that the transformer can answer the question 'have
you changed your behavior' without passing the input stream.

The SQLTransformer is not atomic because it needs the input stream to
understand where the database is, but I18NTransformer (even if it goes
out in an external i18n database) doesn't need the input to understand
if it's own behavior has changed or not.

> > And this in turn would reduce the flexibility of the pipeline:
> > How could I then generate a pipeline which uses more than one (former) transformer,
> > e.g. the SQLTransformer and the I18nTransformer? This would leed to a huge mess
of generators
> > for all possible combinations.
> Why would you use the SQL transformer? It's now fairly well deprecated
> in favour of the ESQL logicsheet. I'm not sure about the i18n
> transformer, because I've not looked at it in detail, but it may well be
> that we can create a logicsheet for that, too.

Please, do not misunderstand my words: I *NEVER* said that *ALL*
transformers should be turned into generators or taglibs, that would be
totally stupid and ruin the concept of pipelines alltogether.

I'm saying that transformers should be atomic as I previously defined to
guarantee caching efficency.

Is this a strong requirement? well, I don't think so: most non-atomic
trasnformers should be generators anyway and those 'real' transformers
are most automatically atomic.

Please, people, based your judgement on the full documents instead of a
few decontextualized fragments in reply.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

View raw message