Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 23213 invoked by uid 500); 22 Jun 2001 16:37:19 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 23175 invoked from network); 22 Jun 2001 16:37:18 -0000 Date: Fri, 22 Jun 2001 12:37:18 -0400 (EDT) From: Donald Ball X-X-Sender: To: Subject: Re: AW: [RT] Alternative Solution to XSP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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. > 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. - donald --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org