My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 3: Unable to readList with XmlReader in Chrome (v7 or v8)
2 people starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  harald.pehl
Closed:  Feb 2011


 
Project Member Reported by harald.pehl, Dec 26, 2010
What steps will reproduce the problem?
1. Create a simple xml document with multiple elements
2. Attempt to use XmlReader.readList

What is the expected output? What do you see instead?

Expect to get a List of objects returned, exception encountered instead
name.pehl.totoe.xml.client.XPathException: (Error): TypeError: Object #<an Element> has no method 'selectSingleNode' stack: Error: TypeError: Object #<an Element> has no method 'selectSingleNode' at [object Object].<anonymous> (unknown source) at __gwt_jsInvoke


What version of the product are you using? On what operating system?
piriti-core 0.6.2 / totoe 0.2.1

Please provide any additional information below.
I believe this is caused by using the Node.selectValue(xpath) method in Totoe.  I can replicate this same behavior by using Totoe directly:

        List<Node> rootChildren = doc.getRoot().getChildren();
        for (Node element : rootChildren) {
            if (element instanceof Element) {
                String value = element.selectValue("//author");  //FAIL
            }
        }

I have a simple project that can reproduce this behavior that I can share.

Issue was moved from https://code.google.com/p/piriti/issues/detail?id=21 to Totoe since it is related to XmlParser / Sarissa.

Dec 26, 2010
Project Member #1 harald.pehl
Comment #9 by Greg.Hengeli from original issue:

...the issue relates to the different context that GWT native code runs in.  When the sarissa_ieemu_xpath.js prototypes the Element object it does so in the main context.  I verified this with the debugger where I saw the selectSingleNode function exist on the Element prototype in the main context while executing a "regular" javascript function as well as in the gwt context when accessing it through $wnd.Element.

HOWEVER - the bug is introduced in the DOMParser.parseFromString function.  This is where I don't have 100% visibility because it is a native function, but I believe when it creates Elements it does so from a different context than either the $wnd.Element (despite the DOMParser being referenced as $wnd.DOMParser) or the main Element.  

So, as a workaround (which I am hoping there is a better solution) in Totoe.XmlParserImpl I created a new method - setupSarissaPrototypes that basically executes a duplicate of the code in the sarissa_ieemu_xpath.js to setup the prototype on Element in whatever context the DOMParser is creating the elements from.

Attached is a copy of the patched XMLParserImpl.
XmlParserImpl.java
5.3 KB   View   Download
Dec 26, 2010
Project Member #2 harald.pehl
 Issue 1  has been merged into this issue.
Feb 18, 2011
Project Member #3 harald.pehl
Implemented the bugfix from Greg. 
Status: Fixed

Powered by Google Project Hosting