Uh, "//[EMAIL PROTECTED]" and "//rule/@name" aren't equivalent XPATH expressions. The first is "all element rule nodes which have a name attribute" while the second is "all name attribute nodes belonging to a rule element node"
Running this with your example gives: <rule name="firstRule"> <subelement name="myAttribute">text here</subelement> <rule name="thirdRule"> <subelement name="myAttribute">text here</subelement> for "//[EMAIL PROTECTED]" and the corresponding 2 name attribute nodes for the "//rule/@name". The first should return an array of two element nodes and the second should return an array of two attribute nodes. I suspect what is happening is that when you do a cfdump, only the content of the node is displayed. Technically, the content of an element node is all the "text" between its enclosing tags (ignoring its attributes), whereas the content of an attribute node is nothing (but it has a value of "firstRule"). Or, in XSL terms, you're expecting <xsl:value-of> behavior while xmlsearch is exhibiting <xsl:copy-of> behavior. So anyways, I would not recommend a rewrite as the two expressions are not equivalent. --- "Dan G. Switzer, II" <[EMAIL PROTECTED]> wrote: > Oh yeah, to workaround the bug, you could write a > UDF that you'd run before > passing the xmlSearch() function that would format > it via an XPath statement > CF likes: > > So, you'd look for strings ending in: > /@attName > > and replace with > [EMAIL PROTECTED] > > You might also just consider writing your own > "xpath()" function to use to > replace the xmlSearch() function. You could then > either choose to use a > Java-based parser, or just reformat strings to make > them CFMX "friendly." > > -Dan > > > -----Original Message----- > > From: Dan G. Switzer, II [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 12, 2003 3:34 PM > > To: CF-Talk > > Subject: RE: XPath in CFMX > > > > Seems like it is a bug. In following example, the > first XPath statement > > works as expected, the second finds 2 matches, but > returns empty arrays. > > > > <cfxml variable="sampleXML"> > > <rules> > > <rule name="firstRule"> > > <subelement name="myAttribute">text > here</subelement> > > </rule> > > <rule> > > <subelement name="myAttribute">text > here</subelement> > > </rule> > > <rule name="thirdRule"> > > <subelement name="myAttribute">text > here</subelement> > > </rule> > > </rules> > > </cfxml> > > > > <!--// works //--> > > <cfset res1 = > xmlSearch(sampleXML,"//[EMAIL PROTECTED]")> > > <cfdump var="#res1#"> > > > > <!--// doesn't work //--> > > <cfset res2 = xmlSearch(sampleXML,"//rule/@name")> > > <cfdump var="#res2#"> > > > > I also know that the XPath expression "rule/@name" > works with the XSLT > > engine--I use that syntax a lot in my XSL sheets. > I think xmlSearch class > > is > > probably the culprit. > > > > -Dan > > > > > -----Original Message----- > > > From: Mueller, Ben > [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, March 12, 2003 2:55 PM > > > To: CF-Talk > > > Subject: RE: XPath in CFMX > > > > > > The problem is not that MACR returns an array > rather than a string in > > this > > > particular XPath case. The problem is that, in > the case where I'm > > trying > > > to > > > get the value of an attribute, it returns an > array of length one that > > > appears to have nothing in it. > > > > > > If you run this code in MX: > > > > > > <cfxml variable="sampleXML"> > > > <rule name="firstRule"> > > > <subelement name="myAttribute">text > here</subelement> > > > </rule> > > > </cfxml> > > > > > > <cfset res1 = xmlSearch(sampleXML,"rule/@name")> > > > <cfdump var=#res1#> > > > > > > ...you'll see that the cfdump of the "res1" > object has no data in it. > > If > > > it > > > returned the value of the attribute somewhere in > the array, I'd be home > > > free. > > > > > > Is there something really basic about this that > I'm missing? > > > > > > > > > -----Original Message----- > > > From: Alexander Sherwood > [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, March 12, 2003 1:47 PM > > > To: CF-Talk > > > Subject: RE: XPath in CFMX > > > > > > > > > At 11:19 AM 3/12/2003 -0600, you wrote: > > > > > > >That's sort of what I was afraid of. If it's > legal XPath syntax, then > > > why > > > >doesn't the XmlSearch function support it? Is > it a weakness in MX, or > > is > > > >this a deliberate omission? And does anybody > know if MM has plans to > > > >support this in the future? > > > > > > Well, i think it has more to do with how MACR > wanted to implement the > > > XMLSearch feature. The W3C spec doesn't specifiy > how the parser should > > > return data, it just specifies that the XPATH > should locate the > > > element/attribute in the document - no matter > what. > > > > > > MACR just decided that they wanted to return an > array instead of say, a > > > string variable or a number. This makes sense > when, in many cases, > > you're > > > not sure how much data is going to come back. > The function is > > standardized > > > to return the same data type on each call: an > array. > > > > > > Look at this Xpath, for example: '//Address'. If > you XMLSearch()'ed on > > > this > > > path and the parser found 4 valid elements, how > would it be returned to > > > you? In an array or some other "collection" like > data type (struct, hash > > > table, etc.). > > > > > > BUT, when you are using XMLSearch() to grab one > element's attribute, how > > > can the function just return you a string, and > not an array? You would > > > have > > > to write code after each function call to > decided how to process the > > > return > > > data. Did I get back an array to loop over or a > string? MACR just went > > > with > > > the array because it make the most sense - > regardless of what the parser > > > finds. Even if you search for one element, you > grab it at index[1], and > > > use > > > XMLAttributes to extract the string or numeric > value. > > > > > > It would be nice, however, to have an > XMLExtractAttribute() function, > > that > > > simply returns the first attribute (in the form > of a string return type) > > > value found for the supplied XPATH. > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > >From: Jochem van Dieten > [mailto:[EMAIL PROTECTED] > > > >Sent: Wednesday, March 12, 2003 11:24 AM > > > >To: CF-Talk > > > >Subject: Re: XPath in CFMX > > > > > > > > > > > >Mueller, Ben wrote: > > > > > Yes, that is exactly what I want. It would > appear (at least from > > > > > Microsoft's website) that this is legal > Xpath syntax. A previous > === message truncated === ===== I-Lin Kuo Macromedia CF5 Advanced Developer Sun Certified Java 2 Programmer __________________________________________________ Do you Yahoo!? Yahoo! Web Hosting - establish your business online http://webhosting.yahoo.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
