Thursday, February 7, 2008

Getting XML Text From XML Nodes

I've been working with XML very heavily the past couple of weeks, and for whatever reason this is just one of those things I haven't had to do a whole lot of until now. Don't get me wrong, XML comes up pretty regularly for most people, but I haven't had to live and breathe it this much before.

As with most things in ColdFusion it's incredibly easy to jump in and get going, and for what I'm doing anyway, XmlSearch makes it absolutely trivial to tear through the XML and get the data I need.

I did run into one annoyance and thought I'd see if anyone had a better solution. Again, since I seem to have dodged working with XML this heavily until now I could just be missing something. Specifically I'm referring to the seeming necessity of two lines to get at most things when you use XmlSearch. If you've worked with XML much in CF you probably already know what I mean. Let's assume there's a single node (meaning really a single element array with an XML node in it) returned by this:

<cfset myXmlNode = XmlSearch(myDoc, "/*/myNode") />

To get at the XmlText, I then have to do this:

<cfset myXmlText = myXmlNode[1].XmlText />

What I'd like to be able to do is this:

<cfset myXmlText = XmlSearch(myDoc, "/*/myNode")[1].XmlText />

But unfortunately that syntax isn't valid. To solve the problem I wrote a little UDF called getXmlTextFromXmlSearch (couldn't think of a longer name ;-) that takes in the array and the element number from which you want the XmlText. It works, but I'm a tad irked that this seems to be necessary. What CF could use IMO is an ArrayGetAt *function* so you could wrap arrays in the function instead of having to jump through these other hoops:

<cfset myXmlText = ArrayGetAt(XmlSearch(myDoc, "/*/myNode"), 1).XmlText />

That's essentially what my UDF does but again, seems a bit klunky. Maybe I'm just nitpicking because ColdFusion is so great and I want it to be perfect. ;-)


I'm in the same boat - I barely use XML but here's what I came up with for an XPath expression to get the xml text:


I'm not sure if it's the perfect solution but I do know XPath is pretty powerful stuff (and I've yet to find a *really* good resource for it).

crud...looks like you stripped my code...let me try this:

<cfxml variable="test">





<cfset text = xmlSearch(test, "string(//nodes/node[text()])") />

<cfdump var="#text#">

Thanks Todd--I'm a bit of an XPath moron so I'll need to look into that more.

You could also do this:

<cfset myXmlText = XmlSearch(myDoc, "/*/myNode").get(0).XmlText />

Ah--didn't think of tapping into the Java that way. That's very slick! Thanks radek!

This will work as well

I wasn't sure how to put code in a comment


#HTMLEditFormat( '')#

Sorry Qasim--I need to tidy up the code handling in the comments!

i don't think it;s the best solution

not sure how i happened upon this, as i'm in virtually the same boat this morning, and your post is already indexed in google - well done!

anyhow, radek is right, arrayGetAt IS array.get(index), and fwiw, arrayFind would be array.indexOf(string)

@todd - I think that the xPath functions such (as string()) are only available in CF8, but I have no way to test on 7 atm.

this xmlSearch will expose whether a function is avail in CF xPath: xmlSearch(search, "function-available('testthisfunction')")

My situation was a *little* different, I wanted to get an array of just the text values in a particular node.


xmlSearch(search, '//nodes/node/text()') returns an array that looks like this:


and i coulnd't for the life of me figure out how to get the xpath search down to just xmlValue...becasue it appears that CF is building that DOM node structure back in to the xmlSearch response. so, xPath finds the text, gives it back to CF, and CF goes 'well, hell, this looks like xml, so let's send it back as native CF XML DOM node structure. as it turns out, in CF8, at least, if i output arr[1], i get a string, and not the XML object shown in the dump of the array.

No comments: