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="http://webslingerZ.com/xml/foo/1.0";
> class="com.webslingerZ.cocoon2.util.FooHandler"/>
> <handler namespace="http://webslingerZ.com/xml/foobar/1.0";
> 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="http://webslingerZ.com/xml/foo/1.0";
> xmlns:foobar="http://webslingerZ.com/xml/foobar/1.0";
> >
> <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
level).
Namespace maps to class name
NS-Prefix maps to class instance
Element maps to method
Sub-Elements maps to named parameters
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
