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).
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.
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.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
