Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: domain of grek@tuffmail.com designates
 216.86.168.178 as permitted sender)
Message-ID: <477448AD.2010708@tuffmail.com>
Date: Fri, 28 Dec 2007 01:51:57 +0100
From: Grzegorz Kossakowski <grek@tuffmail.com>
User-Agent: Thunderbird 2.0.0.9 (X11/20070801)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Broken test-cases due to missing namespace declarations
References: <20071123034959.E83151A983A@eris.apache.org>
 <47464EF1.7030208@gmx.de> <4772A6DC.6020104@tuffmail.com>
 <4772AE12.2080701@gmx.de> <47730D00.3080302@tuffmail.com>
 <47739083.6000909@tuffmail.com> <4773A96A.5000903@gmx.de>
 <4773B017.6020709@tuffmail.com> <4774292B.5070209@gmx.de>
In-Reply-To: <4774292B.5070209@gmx.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Joerg Heinicke pisze:
> 
> It does not just wrap Xalan's DOMBuilder. It kind of does the same but
> has a different approach: Both build a DOM from SAX events but while
> Xalan's does it directly Cocoon's DOMBuilder utilizes a
> TransformerHandler and a DOMResult for it. Additionally listening
> capability is added and XMLPipe implemented. Also Xalan's DOMBuilder is
> more a internal class, it's not part of public API. It's a public class
> but unless you want to tie your code to Xalan there is no way to
> instantiate the class. That's what you usually do using
> SAXTransformerFactory as Cocoon's DOMBuilder does or
> DocumentBuilderFactory. The names matches more or less by coincidence.

Thanks for explanation Joerg! Even I play with Cocoon for some time I don't know low-level details
of Xalan but I think it only proves value of Cocoon that hides all these nasty details. :)


> Our code is not really broken. Usually we call startPrefixMapping() in
> startDocument() methods of transformers or something like this. It's
> only broken for the test cases since we just have a look at the
> "component" to test without its "framework". From a component POV adding
> start/endPrefixMapping() is the "correct" solution to encapsulate it.
> The question I asked was only if these components will ever run outside
> of their current framework. Personally I prefer the "correct" approach
> as well.

I see. Then, agreed with you. Anyway, I have taken effort of tweaking our "components" and
test-cases so all of them pass now. You probably already noticed attached patches to COCOON-2155 issue.
I would like to see them committed as soon as we can upgrade to Xalan 2.7.1.

> 
> I have no idea what the different ways mean in regard of getting things
> done correctly and as fast as possible. I only got the jar from
> Antonio's commit to 2.1 and put it into my local repository by copying
> 2.7.0's POM.

So the question should be addressed to Antonio: Where the jar of Xalan you committed into 2.1.x
branch comes from? :)

-- 
Grzegorz Kossakowski