Return-Path: 
 <cocoon-dev-return-24997-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 89028 invoked by uid 500); 28 Mar 2002 20:11:24 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 89010 invoked from network); 28 Mar 2002 20:11:23 -0000
Message-ID: <3CA3796D.7020209@anyware-tech.com>
Date: Thu, 28 Mar 2002 21:13:33 +0100
From: Sylvain Wallez <sylvain.wallez@anyware-tech.com>
Organization: Anyware Technologies
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9) Gecko/20020311
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Making Xalan XSLTC work with Cocoon
References: <002b01c1d59f$afe45e20$ac00a8c0@Gabriel>
 <3CA22D13.92E3D0C3@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

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

-- 
Sylvain Wallez
 Anyware Technologies                  Apache Cocoon
 http://www.anyware-tech.com           mailto:sylvain@apache.org




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org