Yesterday a reader sent me a question concerning XML handling and ColdFusion, and while it was rather simple, I thought others might like to see a quick demo of it as well. Imagine for a minute this simple XML data.
The XML above describes a simple article. You've got a title, an author object, and paragraphs of text each as their own XML node. The reader simply wanted to know how to get those paragraphs into one string variable. You may be tempted to do this:
But doing so returns you one XML node.
One of the oddities of ColdFusion's XML handling is that it treats some things as a singular value and some things like an array. So if I take the same "address" and run arrayLen() on it, like so...
I'll get 4. This is the clue then that tells us to simply loop over them like an array and append each value to a string.
Note that I've also wrapped the values in P tags to help me display it later.
Archived Comments
I'd be more tempted to xmlSearch() for something like '//article/body/paragraph' which should return an array of nodes, which is a bit more explicit about what is going on when you come to reread the code :-)
Interesting that you said that. The person I helped - she was using xmlSearch. To me, that just feels.... not wrong... but... I don't know. "Direct addressing" - as I did - feels more right. ;)
I normally use XmlSearch myself in a case like this. Purely for performance gains of being able to use a natively compiled library versus the overhead of "directly accessing". The gains are small, but they add up quick for me.
Can't believe how happy I am that CF10 started supporting xpath 2.0.
Jim, can you expound more on the performance gains? This is not something I've heard before. Wouldn't a direct access of a node be quicker than a search, even an optimized search?
It comes down to the underlying java that it gets converted down into.
foo.bar.baz.bobo.wahoo.xmlText
When one goes to access some node in an xml object, coldfusion first has to determine if the root node is a struct or an xml doc. Then, for each successive node, it must compare the next node name with some sort of hash map to identify the next member of the path. Equiv of figuring out that foo.bar is really foo["bar"]. Or possibly depending on the underlying xml classes, figuring out that foo.bar is really foo.getBar() or some other equivelent behind the scenes. This translation takes a little bit of overhead, compounded by each node further down one goes.
Generally, this is trivial and is ignorable under a lot of circumstances as the cost of ease of use versus direct java manipulation.
However, when doing complex pattern matching to identify and collect nodes for work, the above in combination with in-cf logic processing adds up quickly when in comparison to using a java native xpath parser such as xmlSearch provides a bridge to.
Case of proper tool for the job at hand at a given complexity need, much like how ORM is kind of nice, but doesn't fully leverage the power one has of full SQL functionality for complex things.
Fascinating. Thanks for sharing that, Jim.
Hi Raymond. Let's say I have a XML file with A LOT of nodes. Is is possible to parse it and get only the unique nodes. I don't care about the content of the nodes, only want to know which nodes I have in my 31000+ lines XML... Thanks !!
You could store the node values as keys of a struct. That would be a quick/cheap way to ensure uniqueness.
Thank you for your answer. I'll try to find something on the net to help me how to do that.
You don't know how to use structs in ColdFusion? They are pretty easy.
<cfset s = structNew()>
<cfset s["somekey"] = "somevalue">