New Selector Notation Requirement in jQuery 1.5
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.
http://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.
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.
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.
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?
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.
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.
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.