XmlSearch

XmlSearch(xmlDoc, xPathString)

<cffile action="read"
   file="C:\inetpub\wwwroot\examples\employeesimple.xml"
   variable="myxml">
<cfscript>
   myxmldoc = XmlParse(myxml);
   selectedElements = XmlSearch(myxmldoc, "/employee/name/last");
   for (i = 1; i LTE ArrayLen(selectedElements); i = i + 1)
      writeoutput(selectedElements[i].XmlText & "<br>");
</cfscript>

Comments

No screen name said on Aug 19, 2003 at 1:11 PM :

It's worth saying that XmlSearch() works only with XPath expressions that returns a “node list” and, unfortunately, it throw an error if the XPath expression returns a string, a boolean or a number. For example, the code below should return the number of elements available in a XML document, but it throws an error. XmlSearch(xmlDoc,"count(//*)") While the same functionality can be easily achieved accessing the XML doc as a structure, this issue prevents us from taking advantage of many useful XPath functionalities.

MegaLotsACodeASaurus said on Aug 27, 2003 at 4:46 AM :

This string:

"//*[local-name()='xiInterchange']/@timeStamp"

answers the timeStamp in oXygen and XPath Visualizer. When I use it in an XmlSearch() call all I get back is an empty array! Does anybody out there know the *exact* limitiations of the XmlSearch's XPath capabilities. It'd be nice to know exactly what won't work without having to waste hours of time before coming up with a workaround.

MegaLotsACodeASaurus said on Aug 27, 2003 at 4:52 AM :

Having posted and then re-read the documentation I guess I may have answered my own quuestion!? The on-line help says:

An array of XML object nodes that match the search criteria.

Read...object nodes that match...thus one is inherently limited to only asking 'questions that answer object nodes. Surely this has to be either an oversight or a bug. What's the point in being able to ask for a count of nodes called X and then not be able to get hold of the answer! Given the 'typeless' nature of CF in general would it not be better to have the XmlSearch() answer the correctly typed object and the caller would then have to decide what to do with it. Bearing in mind that the query would dictate the return data type this should be too much of a problem I would have thought.
Comments anybody?

jesse s said on Sep 24, 2003 at 6:44 AM :

Unforuntately, XMLSearch is
case sensitive whether or not
the XML DOM is case sensitive.
This means if you're unexpectedly getting no
results, you may need to tweak your
search. To find out which case is being
used in certain attributes, you can CFDUMP the xml file.

carehart said on Nov 13, 2003 at 4:10 PM :

To run the example offered here, be sure to create the employeesimple.xml file as described "earlier" in the docs, at http://livedocs.macromedia.com/coldfusion/6.1/htmldocs/xml4.htm#wp1127213. Just note that the "C:\inetpub\wwwroot\examples\" directory named above may not exist for you, so pay attention to where you save the xml file and change that FILE attribute on CFFILE.

Gary M said on Feb 2, 2004 at 7:30 PM :

Having read this documentation (again) and reading the posts here, I would say that there is a "flaw" (rather than a bug) in the XPATH implementation on CFMX. The documentation clearly refers the reader to the W3C spec on XPATH - but then does not implement that full specification. I think we need a full document on what is and is not supported as mentioned by another person.

TomChiv said on Mar 24, 2004 at 9:31 AM :

There is no indoication here of if the order of the nodes returned will be as they appear in the XML document (and any XMLChildren...) or not...

jrunrandy said on Mar 31, 2004 at 8:01 PM :

the xmlsearch results should be arranged in the same order as they are generated by the underlying xpath engine.

So yes, for simple select expressions, the results should be in the same order as they appeared in the xml document.

Sir Monkey said on Jan 19, 2005 at 7:51 AM :

If anybody has a problem like MegaLotsACodeASaurus, i.e.:

results = XMLSearch(xmlDoc, "//nodes[@searchAttribute = 'value']/@attributeIWant")

And you don't see anything in results, use ToString(results[1]). It's not the most elegant thing I've seen, but it works.

Sir Monkey said on Jan 19, 2005 at 9:02 AM :

Before I forget, using the ToString function on the sample that I mentioned above will also include the XML prolog (<?xml version="1.0" encoding="UTF-8"?>). To get rid of the prolog, use something like Mid to delete the first 40 characters.

davidfekke said on Jan 21, 2005 at 10:35 AM :

XMLSearch will work once you have striped out any xmlns attributes from the root node. This has to be done before you use XMLParse() function. I tried using StructDelete() to remove those attributes from the XML Object, but something in XMLSearch will not work if you have any xmlns attributes in the root node.

TomChiv said on Sep 22, 2005 at 6:39 AM :

Would be nice to have an explanation of the 'XML object node' objects structure here.
I've just had to cfdump the results for the N'th time today, and I can't be the only one.