cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [RT] Alternative Solution to XSP
Date Wed, 27 Jun 2001 09:34:03 GMT
> Donald Ball wrote:
>
> On Fri, 22 Jun 2001, Carsten Ziegeler wrote:
>
> > > right! so what i'm thinking now is that we can write an
> > > InspectionTransformer which can call other Transformers
> seamlessly - at
> > > least, Transformer which have registered themselves as being
> responsible
> > > for a particular namespace. let's see:
> > >
> > Yes, this is actually a transformer I was also thinking of some time ago
> > as I tried to understand why xsp taglibs can be used without any further
> > work then registering them and why transformers have to be declared
> > explicitly in the sitemap.
> >
> > One main problems which is not easily to solve is caching:
> > The InspectionTransformer can not be cacheable and therefore is the
> > disadvantage that the whole transformation stage is not cacheable
> > even if the transformers currently used are cacheable.
> > As most transformers (except the xsl transformer) are highly dynamic
> > this point might be neglectable.
>
> that's certainly a valid point, but consider that xsp pages are not
> cacheable by default. it's the same story at a different stage in the
> pipeline. one could argue that the InspectionTransformer makes it better
> since everything in the pipeline up to the InspectionTransformer is (or at
> least, may be) cacheable.
>
Yes, I agree on this. I always prefered transformers about xsp and as
most transformers do dynamic things they aren't cacheable anyway.

> > I thought of implementing/adding such components like this transformer
> > to a stable and finished C2.0 release, perhaps for starting the C3
> > architecture...
>
> well, i'm hacking on this outside of the main repository for the time
> being since there doesn't seem to be any consensus that it's the right
> approach yet. let me know if you're interested in playing with it.
>
Yes, definitly. Perhaps you could add it to the C2.1 branch as a
"component to be evaluated"? I am really interested in this and think
it is the right approach.

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


Mime
View raw message