Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (nike.apache.org: domain of grek@tuffmail.com designates
 216.86.168.179 as permitted sender)
Message-ID: <476FC74C.9020901@tuffmail.com>
Date: Mon, 24 Dec 2007 15:50:52 +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: JXPathHelper
References: <476F67D2.8060109@dslextreme.com> <476F7647.2090204@tuffmail.com>
 <476F7B3D.4030608@dslextreme.com> <476F7C64.7090800@dslextreme.com>
In-Reply-To: <476F7C64.7090800@dslextreme.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ralph Goers pisze:
> I have verified that the code below gets my new XPathXMLFileModule
> working again. However, I'm still not sure that is the correct thing to
> do as the change essentially broke the contract. So although I could
> make the same change in all the affected Cocoon classes any customer who
> happened to use JXPathHelper for their own purposes would also have
> problems.

I agree that fix for COCOON-2108 changed the contract but I don't agree it broke as I think it's
been broken earlier. Issue COCOON-2108 was caused by the fact that getAttribute was doing something
completely unexpected. Instead of returning an Object it returns String representation of Object.
That's bad situation and if someone relies on bad API it's also his business to fix his code.

I think the best is to introduce new method like getAttributeAsString and switch to it everywhere
it's needed.

-- 
Grzegorz