cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <>
Subject Re: [RT] Alternative Solution to XSP
Date Fri, 22 Jun 2001 05:25:15 GMT
On Thu, 21 Jun 2001, Donald Ball wrote:

> i took a few minutes away from cursing at the pattern substitution code in
> c2 to play around with the xsp replacement strategies we've been tossing
> around. i decided to go ahead and do a simple implementation of the
> InspectionTransformer that i'd suggested. it's attached. NamespaceHandlers
> are registered in the sitemap as follows:
> <map:transformer name="inspection"
>   src="com.webslingerZ.cocoon2.transformation.InspectionTransformer">
>   <handler namespace=""
>     class="com.webslingerZ.cocoon2.util.FooHandler"/>
>   <handler namespace=""
>     class="com.webslingerZ.cocoon2.util.FoobarHandler"/>
> </map:transformer>
> then you can apply it to files like this one:
> <?xml version="1.0"?>
> <root
>   xmlns:foo=""
>   xmlns:foobar=""
> >
>   <foo:bar/>
>   <foobar:bar/>
> </root>
> as you can tell, if you run the examples and poke through the code, if the
> elements produced by the handlers live in one of the namespaces registered
> with the InspectionTransformer, they will end up invoking that namespace's
> handler. this is gobs easier and more reliable than the xsp logicsheet
> application ordering hell that we've got right now. the more i think about
> and play with this, the more i like this paradigm.

Ricardo has developed something similar to this (but at the Genrator

Namespace     maps to   class name
NS-Prefix     maps to   class instance
Element       maps to   method
Sub-Elements  maps to   named parameters


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

View raw message