.. because xmlFirstSearch is NOT a valid
XML
DOC...
The docs say:
Description
Uses an XPath language expression to search an XML document that is
represented as a string variable.
Return value
An array of XML object nodes that match the search criteria.
The result of xmlSearch
The result of xmlSearch() is an array, not an XML doc.
Figured this one out while i was trying the code..
As I said in my previous response:
XPath method works fine without having to loop through all the elements.
I think it would be OK, to work with an Array of Sub-Sets of Larger XML Doc
On Wednesday, Jun 25, 2003, at 18:25 US/Pacific, Joe Eugene wrote:
Another xml XPath ?
How do i just return Book type=Reference Book publication= /
via
xmlSearch()
Since you get back an array of XML sub-objects, you'll always get the
Book ... tag with
all its contents - you could just
Books
Book type=Reference Book publication= /
Author firstName= lastName= /
/Book
Shouldn't this be:
Books
Book type=Reference Book publication=
Author firstName= lastName= /
/Book
Yes.. Just a typo.
But really.. isnt this valid for Dom/XSLT/XPath?
xmlSearch
But really.. isnt this valid for Dom/XSLT/XPath?
xmlSearch(odoc, Books/[EMAIL PROTECTED]'Reference Book']/Book)
Which should only return. Book type=Reference Book publication= /
I would suggest to test you XPath expression with this handy (free) tool:
http://www.vbxml.com/xpathvisualizer
Cant figure this one out OR is it possible in CF xml Notation.
XML..
Books
Book type=Reference Book
TitleJava Programming/Title
AuthorIvor Horton/Author
AuthorIvor Horton/Author
/Book
/Books
Here is what i want to return using XPath...All the Author for node
Here is what i want to return using XPath...All the Author for node
Element Book
cfdump var=#xmlSearch(odoc, Books/Book[1]/Author)#
What is the CF Equivalent to the above in CFMX Notation
odoc.xmlRoot.Book[1]...?
You can get to the elements of Book but that will be an array (I
think
I've get an xml packet that returns qty available per warehouse, and I
want to add up all of the qty's and return a total, but I am getting a
crash when I try and use the sum in the xpath statement.
The xml looks like this.
LineInfo
WhseInfo
IDCodeMIAMI, FL/IDCode
Qty9642/Qty
jon hall [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
This is the error I get.
Can not convert #NUMBER to a NodeList!
Unfortunately xmlSearch() only accept XPath expressions that return a
NodeList, it throws an error in case the expression returns a string or a
number. It's
jon hall [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
This is the error I get.
Can not convert #NUMBER to a NodeList!
Unfortunately xmlSearch() only accept XPath expressions that return a
NodeList, it throws an error in case the expression returns a string or a
number. It's
Tuesday, June 17, 2003, 3:21:00 PM, you wrote:
MF jon hall [EMAIL PROTECTED] wrote in message
MF news:[EMAIL PROTECTED]
This is the error I get.
Can not convert #NUMBER to a NodeList!
MF Unfortunately xmlSearch() only accept XPath expressions that return a
MF NodeList, it throws an error
node and get it's absolute
path. i.e.
\root\car\tyres.
Can you use Axes with CFMX http://www.w3.org/TR/xpath#axes
Thanks
~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http
Paul Wilson [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
root
car
engine/
tyres/
gears/
/car
/root
I want to know all of the parents/ancestors of the tyres node and get it's
absolute path. i.e.
\root\car\tyres.
Can you use Axes with CFMX http://www.w3.org/TR/xpath#axes
I don't know what parser CFMX uses, though since I know nothing about the
details of parsers, if I did know the name of the parser they are using,
that wouldn't help me one iota (-;
The Xpath example you are using below is not quite what I am after. Your
example:
cfset xRes=xmlSearch(odoc
CFMX uses:
Apache Crimson parser for server side xml parsing
Xalam Parser for XSLT.
Tkx,
Jim
-Original Message-
From: Mueller, Ben [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2003 8:46 AM
To: CF-Talk
Subject: RE: XPath in CFMX
I don't know what parser CFMX uses, though since
Eugene [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 11:13 PM
To: CF-Talk
Ben,
The only difference is see from plain XPath, is using
(XmlChildren,XmlText,XmlAttributes).
Example
?xml version=1.0 encoding=UTF-8?
Books
Book type=Reference Book
TitleJava Programming/Title
AuthorIvor
-
From: James Alexander [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2003 8:32 AM
To: CF-Talk
Subject: RE: XPath in CFMX
MX uses a DOM parser. SAX parsers by their very nature are event driven,
and well, CF isn't an event driven language. There is however a handful
of Java SAX parsers
If you're not using the MSXML parser in IE6, then the xpath stuff you're
writing may not be w3c standard. MS came out with an implementation of
xpath (and xsl in general) that followed the beta standards in IE5/5.5,
which is different than the released standard.
I can check at work once I'm
At 07:45 AM 3/12/2003 -0600, you wrote:
I don't know what parser CFMX uses, though since I know nothing about the
details of parsers, if I did know the name of the parser they are using,
that wouldn't help me one iota (-;
The Xpath example you are using below is not quite what I am after
Yes, that is exactly what I want. It would appear (at least from
Microsoft's website) that this is legal Xpath syntax. A previous poster
suggested that this may have been an extension MS made that falls outside
the w3c spec. At this point, I'd be happy with confirmation that a call
like Books
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 poster
suggested that this may have been an extension MS made that falls outside
the w3c spec. At this point, I'd be happy with confirmation
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?
-Original Message-
From: Jochem van
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
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
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
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=myAttributetext here/subelement
/rule
rule
This is exactly the behavior I get--or don't get. (-;
So...off to the bug reporting portion of MM's website.
-Original Message-
From: Dan G. Switzer, II [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2003 2:34 PM
To: CF-Talk
Subject: RE: XPath in CFMX
Seems like it is a bug
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
Yeah, we've already considered option 1, and we may in fact do that. We
also may end up re-designing our XML structure at some point down the road,
which could obviate the need for this particular Xpath call. But, those
points aside, it's still mucho annoying that this doesn't work
this issue to MM. I'd definitely consider it a
bug--since it is valid XPath syntax and it's obvious that it's finding the
nodes, it's just not returning the correct data.
-Dan
-Original Message-
From: Mueller, Ben [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2003 3:43 PM
To: CF
At 02:43 PM 3/12/2003 -0600, you wrote:
Yeah, we've already considered option 1, and we may in fact do that. We
also may end up re-designing our XML structure at some point down the road,
which could obviate the need for this particular Xpath call. But, those
points aside, it's still mucho
It has been reported to MM. Now we wait...
-Original Message-
From: Dan G. Switzer, II [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2003 3:11 PM
To: CF-Talk
Subject: RE: XPath in CFMX
I'd almost recommend option 2--because it opens the door a little more. If
you choose to use
overshadowed by Xerces.
-Original Message-
From: Alexander Sherwood [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2003 1:04 PM
To: CF-Talk
Subject: RE: XPath in CFMX
At 02:43 PM 3/12/2003 -0600, you wrote:
Yeah, we've already considered option 1, and we may in fact do
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
At 01:42 PM 3/12/2003 -0800, you wrote:
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
Crimson looks like it's been killed.
Xerces is a parser. Xalan is a transformation engine.
- Original Message -
From: Barney Boisvert [EMAIL PROTECTED]
Date: Wednesday, March 12, 2003 2:41 pm
Subject: RE: XPath in CFMX
I'd use one of the packages from Apache, depending on your
Uh, //[EMAIL PROTECTED] and //rule/@name aren't
equivalent XPATH expressions.
snip Understood. But I think the previous poster was suggesting that, as
a workaround for this problem, you could, using something like a regular
expression replace, change the second Xpath call into the first call
Crimson looks like it's been killed.
Xerces is a parser. Xalan is a transformation engine.
Yes, Crimson was rolled into Xerces 2 in the late fall some time. It is a
hibernated project right now, which is to say that it's no longer being
actively developed.
Look into Xerces 2.
Regards,
Dave.
The Xpath example you are using below is not quite what I am after. Your
example:
cfset xRes=xmlSearch(odoc, /Books/[EMAIL PROTECTED]'Reference Book'])
The reason why i posted the above was because you were trying to use
xmlSearch, which logically means you are searching(xml*Search
Carabetta [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 12, 2003 5:26 PM
To: CF-Talk
Subject: RE: XPath in CFMX
Crimson looks like it's been killed.
Xerces is a parser. Xalan is a transformation engine.
Yes, Crimson was rolled into Xerces 2 in the late fall some time
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
You are correct, but the problem stems more from the way Macromedia
Are you suggesting that the value I'm after is
somewhere in the returned
object, but cfdump doesn't know how to handle it, or
that XmlSearch isn't
returning it at all. If it's the former, then I'd
love to know how to
access that information.
I haven't worked with xml inside of CFMX to
My company is in the process of moving over to MX, and I have been tasked
with upgrading our XML handling custom tags to MX compliance. I have
discovered what appears to be a bug in the way MX handles Xpath, and if it
isn't a bug, then it's a deviation away from the standard implementation
Ben,
The only difference is see from plain XPath, is using
(XmlChildren,XmlText,XmlAttributes).
Example
?xml version=1.0 encoding=UTF-8?
Books
Book type=Reference Book
TitleJava Programming/Title
AuthorIvor Horton/Author
/Book
/Books
cfset odoc=xmlParse(books)
cfoutput
101 - 144 of 144 matches
Mail list logo
