Repository navigation
XML DropDownList restricted to attributes - why not an XPath? #5
Description
When using the XML DropDownList datatype I can specify an XPath expression to select the nodes in the XML file that should be "selectable" - but I was completely baffled as to why the "Text column" and "Value column" values didn't work. My XML file looked like this:
<items>
<item>
<ITEMNUMBER>30401020</ITEMNUMBER>
<field>
<fieldname>ITEMNAME</fieldname>
<value>Mountain Bike</value>
</field>
</item>
...
</items>And I had set the XPath to /items/item[field/fieldName = 'ITEMNAME'], the Text column to field/value and the Value column to ITEMNUMBER.
Upon closer reading I did at least grasp that the columns are referred to as "fields" and in my testing it seems like they can only select attributes on the selected node...
I see this as somewhat restrictive, because it means I'll have to pre-process the XML to move data into attributes.
So I guess my suggestion is to allow the Text and Value columns to use an XPath selector?
Activity
leekelleher commentedon Jan 27, 2014
@greystate Thanks for raising this, I'll take a look and see if I can work out a solution.
leekelleher commentedon Mar 27, 2014
@greystate Finally got around to looking at this.
Not good news I'm afraid. Internally the data-type uses .NET's built-in
XmlDataSourcecontrol, which (now I've researched it - you're correct) only supports using the attribute values of the matching nodes.I have an idea on how to resolve this, but might be tricky without breaking backwards-compatibility.
Watch this space.
Fixed #5 - enabled XML DropDownList to use XPath
leekelleher commentedon Mar 27, 2014
... and I figured out a way to maintain backwards-compatibility! 😺
The code fix checks if the "XPath" matches an attribute name, if so uses that - otherwise it applies the XPath to the matched node to get the text/value.
I've added this to the v6.0.1 branch (no set release date yet)
greystate commentedon Mar 28, 2014
Great news - I'd just been looking at this a couple of days ago and had come to the same conclusion when I forund that it used a built-in class (I was all "where the **** is all the code that does this??? :-)
So theoretically this will fail in the highly unlikely case of a matched element having a child element with the same name as an attribute and I really need the child element's value, right? I can totally never see that happening, so that's just swell.
Thanks Lee - you rock 🎸
leekelleher commentedon Mar 28, 2014
@greystate You're correct, if an attribute and child element had the same name, then the attribute would "win". One way to get around that could be to add a predicate/selector? e.g.
sameName[1]... as .NET does a literal match on the attribute's name.greystate commentedon Mar 28, 2014
Ah yes - that'd probably work; but again, I can't see that happening - not even MSSQL's "FOR XML" output is that bad :-)