SharePoint’s Web Services, jQuery, and the z:row Namespace in Safari and Chrome
<UPDATE date=”2011-02-14″>: As of jQuery 1.5, single quotes are *required* around z:row or any other similar node selector. This was actually “required” in previous versions of jQuery, but not enforced.
$(xData.responseXML).find("[nodeName='z:row']")
</UPDATE>
jQuery’s totally cross-browser capable, right? Well, generally, yes. However, through no fault of jQuery, Safari and Chrome don’t seem to like the z:row namespace that the SharePoint Lists Web Service GetListItems operation returns. I found a nice workaround for z:row from Mike Hacker to improve cross-browser compatibility. I added a check for ItemCount up front so that we don’t try to use the getElementsByTagNameNS function in IE if there have been no rows returned legitimately.
<UPDATE date=”2009-12-09″>: I’ve arrived at a better answer for the z:row (or any namespaced XML) selector issue based on something even simpler from Kevin Whinnery. A nice side benefit of this approach is that it seems to work with Safari on the Mac, though since I don’t have access to a Mac, I haven’t tested very much.
$(xData.responseXML).find("[nodeName=z:row]")
</UPDATE>
Here’s my function. I call it with the XMLHttpRequest result wherever I’m using GetListItems to get a usable rowset regardless of the browser.
// Find the rows in an XMLHttpRequest. This includes a workaround for Safari and Chrome's
// aversion to the z:row namespace.
function getZRows(rXML) {
var rows;
var itemCount = $(rXML).find("rs\\:data").attr("ItemCount");
if (rXML.getElementsByTagName("z:row").length == 0 && itemCount == undefined) {
rows = rXML.getElementsByTagNameNS("*", "row");
} else {
rows = rXML.getElementsByTagName("z:row");
}
return rows;
}
I’ve tested this in IE8, Firefox, Safari, and Chrome on my Windows PC. It still doesn’t seem to solve the issue on Safari for Mac, but I’m getting there. This will at least let the functions in v0.5.0 of my jQuery Library for SharePoint Web Services work with all of the main browsers on the Windows side of things.
Marc, you can simplify this expression:
rows = rXML.getElementsByTagName(“z:row”)||rXML.getElementsByTagNameNS(“*”,”row”);
This is what I use on the image rotator for example (see the “build your own” tab):
http://www.pathtosharepoint.com/Pages/ImageRotator.aspx
This is ok in plain JavaScript, but for jQuery there’s actually a better way:
$(rXML).find(“rows”)
That’s it!
The downside is that jQuery doesn’t handle namespaces, so you may need to add a namespace test later in the script. However, it doesn’t seem to be a concern here, as you were using a wildcard.
Thanks, Christophe. As with anything, this library is under continual improvement (I hope!). Suggestions like this are always helpful.
M.
The bad news: the “find” method I suggested above doesn’t seem to work so well (at least with multiple namespaces).
The good news: the workaround below seems to address the issue:
http://kevinwhinnery.com/post/165178165/jquery-xml-parsing-and-xml-namespaces
If you test it, I’d be interested in your conclusions, as I plan to use it myself.
Christophe:
I like Kevin Whinnery’s approach much more than mine because it’s cleaner, smaller code. I just did a quick test, and this:
$(xData.responseXML).find("[nodeName=z:row]")
seems to work fine in IE, Firefox, Safari, and Chrome. I’ll want to do some more testing before I declare victory, but I like it, and thanks!
M.
Hi Marc,
Just wanted to say thanks for posting this. Works great for me, and saved my a bunch of time trying to figure out another solution.
Take care.
Thanks Marc and Kevin,
Superb fix, just what I needed :)
$(xData.responseXML).find(“[nodeName=z:row]”) does the job for me.
Thanks a lot.. I googled and got what am looking for. But the page is not active. I found in Google Cache.
Go figure… This old post helped me with my Web Services assignment. Good stuff!
“[nodeName=z:row]” seems to be significantly slower than
“z\\:row” on IE8. It’s slow enough that it seems to cause a
responsiveness error on IE8 if I have several other Ajax calls
going on. So, I’m just going to put in some conditional processing
to give one find statement if running on IE, or the max
compatibility “nodeName” statement if not. Thoughts?
J.P:
I’m surprised that you are seeing such a noticeable difference in the selector methods. How have you measured it? If you have some empirical data, I’d be happy to see if I can reproduce it.
M.
I have been struggling with this inconsistent behaviour
from IE8, and thanks a lot for this solution!
# re: jQuery Slideshow
Found this … and it’s working for me.
$(xData.responseXML).find(“z\\:row, row”).each(function(i)
http://bugs.jquery.com/ticket/10377
Terri:
That works for now, but since there have been several changes to what works for this I created the SPFilterNode function in SPServices. This should help future-proof your code, as I can change the function to cover any changes the jQuery team makes in the future.
M.