1. #1
    Sencha User
    Join Date
    May 2012
    Posts
    19
    Answers
    4
    Vote Rating
    0
    BionicGeek is on a distinguished road

      0  

    Default Answered: Use XmlReader/AutoBeans to parse XML that has attributes in the element?

    Answered: Use XmlReader/AutoBeans to parse XML that has attributes in the element?


    Can the XmlReader in conjunction with AutoBeans process an XML message that has attributes within the root node element?

    The GXT example (which works just fine) uses relatively simple XML:

    <record>
    <name>SampleName</name>
    <Email>sampleemail@email.com</Email>
    </record>

    However, what if the root node has attributes or namespace declarations in it?

    <record xmlns:ab="http://anykindofnamespace.com">
    <ab:name>SampleName</ab:name>
    <ab:Email>sampleemail@email.com</ab:Email>
    </record>

    When I attempt to parse this kind of XML it seems that the XmlReader thinks it can't find a matching node, event if I use a PropertyName declaration (e.g. @PropertyName("record")).

    Any suggestions would be greatly appreciated.

  2. Just answered your SO post, but it is worth posting again here for others who hit this:

    GXT's XmlReader sits on top of the build in XML parser that exists in the browser itself. It uses the com.google.gwt.xml.XML module in GWT to gain relatively consistent access to the XML nodes across all browsers, rather than building its own XML parser. By using the built-in implementation in the browser, GXT gets access to the native parser - and it turns out browsers are very good at parsing XML, since that's what they do all day, loading webpages.

    Then, GXT has its own query engine to find nodes, in a query language that uses a combination of XPath and CSS3. This mix is to allow it to work well for looking for nodes in the html itself, as well as looking for nodes in xml documents. This is designed to be consisten
    However, browsers have inconsistent support (I'm looking at you, IE) for namespaces, and so the XML module in GWT doesn't know how to talk about namespaces, and the DomQuery engine doesnt really either. Additionally, the : operator, which in XML means 'namespace', is used to mean 'psuedo-selector' in CSS, so the query language would be a little vague if it supported this directly: The string foo:bar could either mean "All elements with name foo that match psuedo-selector bar", or "All elements with name bar in the namespace foo".
    So enough with the problem: whats the solution? At present, there isn't a good one for namespaced elements in IE6/IE7/IE8 - one part inconsistencies in the browsers and one part lack of ugly workaround in GXT means that you can't read out the elements directly. For all other browsers, to select elements like namespace:eltname, just use @PropertyName("eltname").
    One other note: Due to the fact that attributes don't have psuedo-selectors, you can select them - @PropertyName("namespace:attrname") will correctly read out values in the attribute in <element namespace:attrname="value">.

    To be clear, this is something we are interested in fixing, but are lacking a good way to do so - the way to change the DomQuery implementation to always find these elements ends up making IE's element lookups even slower than they currently are, and this would slow down all IE DomQuery lookups, just to fix this issue in XML documents with namespaces. To that end, we're considering two options for changing the library:
    * Add a specific operator for namespace (probably either the 'namespace-uri()' xpath method, or the | css namespace operator), or
    * Make a specific XmlReader implementation for document traversal, so we don't need to deal with CSS

    The first solution would either mean that you could read with XmlReader but not write with XmlWriter, or that we would use the mostly unknown | operator for namespaces - both of these seem to add maintainability problems, so I'm hesitant to consider them. The second solution would be a breaking change in the API, so would need to come at a minor release, and would require more work, so would need more time until it is ready.

  3. #2
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,717
    Answers
    109
    Vote Rating
    88
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    Just answered your SO post, but it is worth posting again here for others who hit this:

    GXT's XmlReader sits on top of the build in XML parser that exists in the browser itself. It uses the com.google.gwt.xml.XML module in GWT to gain relatively consistent access to the XML nodes across all browsers, rather than building its own XML parser. By using the built-in implementation in the browser, GXT gets access to the native parser - and it turns out browsers are very good at parsing XML, since that's what they do all day, loading webpages.

    Then, GXT has its own query engine to find nodes, in a query language that uses a combination of XPath and CSS3. This mix is to allow it to work well for looking for nodes in the html itself, as well as looking for nodes in xml documents. This is designed to be consisten
    However, browsers have inconsistent support (I'm looking at you, IE) for namespaces, and so the XML module in GWT doesn't know how to talk about namespaces, and the DomQuery engine doesnt really either. Additionally, the : operator, which in XML means 'namespace', is used to mean 'psuedo-selector' in CSS, so the query language would be a little vague if it supported this directly: The string foo:bar could either mean "All elements with name foo that match psuedo-selector bar", or "All elements with name bar in the namespace foo".
    So enough with the problem: whats the solution? At present, there isn't a good one for namespaced elements in IE6/IE7/IE8 - one part inconsistencies in the browsers and one part lack of ugly workaround in GXT means that you can't read out the elements directly. For all other browsers, to select elements like namespace:eltname, just use @PropertyName("eltname").
    One other note: Due to the fact that attributes don't have psuedo-selectors, you can select them - @PropertyName("namespace:attrname") will correctly read out values in the attribute in <element namespace:attrname="value">.

    To be clear, this is something we are interested in fixing, but are lacking a good way to do so - the way to change the DomQuery implementation to always find these elements ends up making IE's element lookups even slower than they currently are, and this would slow down all IE DomQuery lookups, just to fix this issue in XML documents with namespaces. To that end, we're considering two options for changing the library:
    * Add a specific operator for namespace (probably either the 'namespace-uri()' xpath method, or the | css namespace operator), or
    * Make a specific XmlReader implementation for document traversal, so we don't need to deal with CSS

    The first solution would either mean that you could read with XmlReader but not write with XmlWriter, or that we would use the mostly unknown | operator for namespaces - both of these seem to add maintainability problems, so I'm hesitant to consider them. The second solution would be a breaking change in the API, so would need to come at a minor release, and would require more work, so would need more time until it is ready.

Thread Participants: 1