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.

Similar Posts

17 Comments

  1. 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.

    1. Thanks, Christophe. As with anything, this library is under continual improvement (I hope!). Suggestions like this are always helpful.

      M.

  2. 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.

    1. 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.

  3. Thanks a lot.. I googled and got what am looking for. But the page is not active. I found in Google Cache.

  4. “[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?

    1. 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.

    1. 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.