cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <Ralph.Go...@dslextreme.com>
Subject Re: JXPathHelper
Date Mon, 24 Dec 2007 09:31:16 GMT
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.

Ralph

Ralph Goers wrote:
> As far as I know the old implement wasn't buggy,it just always 
> returned text. It looks like it could have returned null and the code 
> might not handle that properly, but that isn't a problem in 
> JXPathHelper.  The proper way to have done this would have been to 
> either have created a new method - since the return type was really 
> always a String, although it is specified as object, or to have gone 
> and fixed everything that that used getAttribute to work correctly. It 
> looks like adding
>
> if (result != null && result instanceof Element) {
>  result = ((Element)result).getTextContent();
> }
>
> might fix this, but I'll have to add it to everything that uses 
> JXPathHelper.getAttribute, which doesn't seem quite right either.  But 
> I'm testing this right now to see if it fixes this.
>
> Ralph
>
> Grzegorz Kossakowski wrote:
>> Ralph Goers pisze:
>>  
>>> I am going to have to revert the change below to JXPathHelper as it has
>>> broken XMLFileModule. The sample site no longer works correctly.
>>>     
>>
>> Hi Ralph.
>>
>> Are you sure that simple revert is a solution? AFAIR previous 
>> behavior of
>> JXPathHelper.getAttribute() method was buggy too.
>>
>>   

Mime
View raw message