cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Davanum Srinivas <d...@yahoo.com>
Subject Re: AW: [RT] Alternative Solution to XSP
Date Wed, 27 Jun 2001 10:23:08 GMT
+1 for adding the InspectionTransformer code into 2.1.

Thanks,
dims

--- Carsten Ziegeler <cziegeler@sundn.de> wrote:
> > 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
> 


=====
Davanum Srinivas, JNI-FAQ Manager
http://www.jGuru.com/faq/JNI

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from 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


Mime
View raw message