Stefano Mazzocchi wrote:
>Sylvain Wallez wrote:
>
>>So what about a new VersatileTrAXTransformer that would be the "old" one
>>(i.e. doesn't use XSLTProcessor) with a configurable TransformerFactory
>>? This would then avoid a new CS used only by the TrAXTransformer and
>>the need for "hacky" subroles.
>>
>
>Yeah, makes perfect sense.
>
>In fact, the use of XSLT 'internally' is way different than the use of
>XSLT 'externally' (that is, at the application level rather than at core
>level).
>
Agree.
>I would go even further: I would change the *existing* TrAXTransformer
>to use TrAX directly and not add yet another transformer that
>behaviorally does the exact same thing.
>
Agree also. Keeping the old one only for back compatibility would
confuse users ("Why is there 2 TrAXTransformer ?")
>So, let's see, here are the proposed changes now:
>
> 1) decouple TrAXTransformer from the internal Cocoon components and
>make it use TrAX directly.
>
> 2) remove the <xslt-processor-role> parameter
>
> 3) add a <trax-factory> parameter to indicate which class should be
>used as a TrAX factory.
>
>That's it. It is *slightly* back compatible, but I'm sure that cocoon
>users care *only* for the ability to have their own XSLT implementation
>only at user level (in fact, changing the xslt-processor component
>implementation just creates problems since we are basing our behavior on
>xalan-only features so far).
>
>If I don't receive any -1, I'll go ahead and patch it.
>
+10 ;-)
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
