cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Making Xalan XSLTC work with Cocoon
Date Thu, 28 Mar 2002 20:13:33 GMT
Stefano Mazzocchi wrote:

>Berin and Sylvain wrote:
><snipped bunch of useful stuff/>
>Ok, we can do it today, but I think that we *must* patch the
>TrAXTransformer in order to avoid users from being able to configure a
>ROLE (which is pretty bad thing).
>Unfortunately, the patches will make the system back incompatible for
>those of you that use external XSLT implementations, but we are aiming
>for 2.1 so I think this would be fair.
>So, the plan is to change to provide a hint for the CS and not a role
>for the CM.
>Does anybody disagree on this action?
>Berin, as far for cleaner implementation I agree that it's not that
>perfect, but anyway, it works and we are not extending this anymore in
>the future since TrAX already provides us with great abstraction from
>the implementations.

In the "ancient times" of Cocoon 2, there was no XSLTProcessor : 
TrAXTransformer used directly the TrAX API, and some other components 
(mainly the markup language engine) used it directly also. Then came the 
XSLTProcessor to factorize things and make the "grand unification" of 
XSLT processing in Cocoon.

Now we see that the TrAXTransformer needs to deal with various engines. 
However, I still have the impression that other uses of the 
XSLTProcessor are more "core" to Cocoon (that's mainly logicsheets), and 
that using there a single engine would be ok.

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.

Thoughts ?


Sylvain Wallez
 Anyware Technologies                  Apache Cocoon 

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

View raw message