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.
