SharePoint Info
Latest tweets
Loading tweets...
Follow @sympmarc
« Finding the Contents of a SharePoint Rich Text Column with jQuery – And Changing It
Displaying Links Lists’ URLs in a Content Query Web Part (CQWP) in SharePoint 2010 »
Feb 15 2011
Print this Post
New Selector Notation Requirement in jQuery 1.5
SharePoint
by Marc
February 15, 2011
In a post on February 3 entitled Issues with SPServices and jQuery 1.5, I mentioned that there were some problems with SPServices and jQuery 1.5. Since then I’ve done pretty extensive testing, and I’m convinced that the only problem is that, 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']")
(good)
vs.
$(xData.responseXML).find("[nodeName=z:row]")
(bad)
Matt Bramer (@IOnline247) tracked down a specific "bug" on the jQuery site about this and added this comment to my prior post:
I’ve found “bug” in the jQuery Bug Tracker.
bugs.jquery.com/ticket/8120
Looks like now they just require quotes instead of it being a best practice.
Thanks, Matt for finding that to confirm what I was seeing in my testing.
The symptom of this is that the z:row selector simply doesn't work, so it seems like you've received no items back from a Web Services call, in the case of SPServices.
The moral of the story is: If you have jQuery in place and you upgrade to jQuery to 1.5, your scripts may break. Thorough testing is *always* a good idea, and in this case, there's what amounts to a "known issue" to look out for. Be sure to check ALL of your selectors, not just those that use the z:row namespace, for the single quotes. They were always a good idea; now they are a requirement.
Share:
This post has no tag
6 comments
3 pings
Skip to comment form ↓
Christophe
February 15, 2011 at 1:20 am (UTC -5) Link to this comment
Reply
Marc: for me, this confirms that it is a good practice to keep an explicit version number when you deal with external libraries. For example, call “jQuery-1.4.4.js”, not “jQuery-latest.js” or “jQuery-current.js”. I’d be interested in your take on this.
Marc
February 15, 2011 at 6:44 am (UTC -5) Link to this comment
Reply
Christophe:
I always recommend using explicit filenames as well. You need to know what version you’re working with.
Mark Rackley has a nice hybrid trick. Since he keeps his .js files in a Document Library, he uses a generic filename, e.g.. jquery-latest.js, and uses a column to store the version number. This means he doesn’t need to change script src references, but he can still be sure of the version.
I still like to use the explicit references so that I can test each occurrence before upgrading. The SPScriptAudit function in SPServices can help manage the process.
M.
Matt Bramer
February 15, 2011 at 8:42 am (UTC -5) Link to this comment
Reply
What I’ve been doing is storing all versions of jQuery in a doc lib and when a new one come out, point that to jQuery-current.js. Then I take the old version and give it a version number: jQuery-1.4.4.js. I find it’s easier to upgrade all of the script src’s all at once and then find the one’s that break and downgrade them if necessary.
What’s your take on that guys?
Marc
February 15, 2011 at 8:47 am (UTC -5) Link to this comment
Reply
Matt:
If it works for you, then it’s great! I worry about the “find the ones that break and downgrade them if necessary” statement, though. That means that you aren’t doing enough testing. If you test ahead of time, then nothing should break.
M.
Christophe
February 15, 2011 at 9:10 am (UTC -5) Link to this comment
Reply
Well, Matt, that was my point, easy vs. reliable. With your method, you would have broken all your pages that use the faulty selector.
For SPServices, we are lucky because the author has identified and fixed the issue. I use other plugins that haven’t been updated in a while. So, to respond to Marc comment, if testing with the new version of jQuery breaks, then I’ll just stay with the previous version until I have an alternate option. I might even have to juggle with several versions of jQuery on a same site. Hence my comment.
Marc
February 16, 2011 at 9:37 am (UTC -5) Link to this comment
Reply
One other aspect that none of us has mentioned yet is caching. Depending on your network topology, using the same filename can be problematic. I’ve had to go throguh all sorts of machinations
to get around so-called “smart” caching scenarios. F5s, in particular, can make it difficult (at least when they are set up incorrectly).
If you want to be certain which file your users are using in their browsers, fresh filenames for the jQuery library as well as your own script files can be a good idea.
M.
Updated SharePoint 2010 Certifications for SPServices « Marc D Anderson's Blog
February 25, 2011 at 6:06 pm (UTC -5) Link to this comment
Reply
[...] I wanted to make these updates as part of getting ready for releasing v0.6.0. This version will be the most significant overhaul of SPServices to date, with lots of great enhancements. You can see the current status of things by looking at the v0.6.0 release in the Issue Tracker at any time. I may defer some of the remaining enhancements to v0.6.1 because I want to get v0.6.0 out there to eliminate the known issue with jQuery 1.5. [...]
Issues with SPServices and jQuery 1.5 « Marc D Anderson's Blog
March 6, 2011 at 10:48 am (UTC -5) Link to this comment
Reply
[...] I hope to release soon. However, in your own code, be sure to add the single quotes! Also see my follow up post. [...]
jQuery and Backward Compatibility « Marc D Anderson's Blog
June 27, 2011 at 12:36 pm (UTC -5) Link to this comment
Reply