A jQuery Library for SharePoint Web Services (WSS 3.0 and MOSS): Part 1 – Why and Why Now?

Cross-posted from endusersharepoint.com…

Even back in the old days (late 2006) when I first started working with SharePoint 2007, I was surprised how little interactivity there was within pages.  Sure the drag and drop way to add Web Parts to pages and move them around had some “wow factor”, but most users wouldn’t even get to see that. 

In general, the UI for the average user was a do-something-and-watch-the-page-refresh affair.  There were good considerations for this decision on the Microsoft end, I’m sure, with cross-browser issues being a significant one.  It also takes a long time to develop an enterprise-class application platform like SharePoint, and the Web is evolving too fast to keep up with UX trends willy-nilly.

For a while I’d heard a constant murmur about jQuery as something that was becoming hot.  Paul Grenier’s jQuery for Everyone series here at EUSP certainly reinforced that.  Looking back through my blog posts, the first time I really tried to get something done with jQuery was in July, 2009 (Onward and Upward with jQuery: Reworking My External Links JavaScript).  I was amazed at how easy it was to bring some quick “Web 2.0” type functionality to SharePoint.  I was hooked.

Roll forward just a few weeks, and I spotted a really nice blog post from Mike Oryszak which showed how to update an item without a form by using jQuery to post changes using the SharePoint Lists Web Service. It got me thinking about a lot more things that you might do to make SharePoint feel more “Web 2.0″.  By using jQuery, you could quickly add functionality to your pages, and in this case, even use its AJAX capabilities to talk to Web Services.

For those of you who don’t know (skip this bit if you do), SharePoint’s Web Services let you “talk” to SharePoint in real time without writing any Visual Studio-based code, unless you want to.  Web Services accept well-formed input (in SharePoint’s case, XML) and return well-formed output (again, XML).  I’ll explain the specific Web Services later, but with them, you can accomplish some of the more significant operations you might need to make SharePoint’s aspx pages more interactive.  You can ask the Web Services about things (typically the operations which start with Get: GetList, GetWeb, etc.) as well as do updates (generally operations which start with Add, Update, or Delete/Remove: AddList, UpdateListItems, DeleteAlerts).

It hit me later that same day: a jQuery Library for SharePoint Web Services would be a really fun and useful thing to build.  All of the AJAX-y stuff that I was seeing in posts from bright people like Jan Tielens, Paul Grenier, etc. felt to me a little too one-off.  I thought it would provide a lot of power to wrap these Web Services consistently so that developers could forget the SOAPy mess (there are some annoying inconsistencies in how the individual operations for the Web Services work) that Web Services need and just get things done easily and fast.

Well, what about SharePoint 2010, you might ask?  Won’t it provide things like you’re doing out of the box?  Won’t the Web Services change?  Well, all of this may be the case, but SharePoint 2007, whether it be WSS 3.0 or MOSS, is not going away anytime soon.  Organizations are definitely playing the “more with less” game right now, and I don’t see that changing anytime soon.  That means no expensive (whether the expense is in licensing or in plain old time spent) upgrades. 

Large organizations also just don’t move fast.  They will want to put SharePoint 2010 into the lab when it comes out and kick the tires, perhaps for a long time, until they decide to upgrade.  And let’s not forget the 2003-2007 upgrade process, which left many folks with a bad taste in their mouths for what they think that this upgrade may bring.  So, why isn’t now a good time for this jQuery library?  We should be able to get a good 18 months or more of good use out of it.

That was the genesis and some of the thinking, and I decided to follow a few simple rules:

1. KISS – Keep It Simple and Stupid  — This meant wrapping the Web Services as they stand, using the same elements and element names that you’d use if you worked with the Web Services directly. It also meant keeping the code readable.  When I use open source stuff, I want to understand what’s going on in there.  I’ve tried to keep the code as clear as I can so that developers can dig in and understand it.  Maybe that means it doesn’t look as cerebral as some other code I’ve seen, but simplicity can be beautiful, too.
2. Leave error management to the developer – This may evolve, but the idea here is to just pass what the Web Service calls return back and do no “value add” in the process.  I have no idea how the developer is going to use these Web Services, and adding alerts or pop-ups or injecting my own text into the error if there is a problem may be totally counter to those goals. (Let me know if you have strong opinions on this.  One thought is to turn on a “debug” mode for development, which you would turn off in actual usage.  We’ve also provided the $().SPServices.SPDebugXMLHttpResult function so that you can inspect the XML which is returned easily on a Web page.)
3. Build the cool stuff – These Web Services are groovy and all, but what can you actually get done with them?  Well, I knew of some really obvious choices from my blog.  My cascading downloads posts have consistently been among the most read, so building the $().SPServices.SPCascadeDropdowns function was almost a no-brainer, and I know that people are using it to solve real business requirements.

So there’s a little background on how I have gotten where I have with the jQuery Library for SharePoint Web Services.  My goal is to keep it moving forward with the “cool” stuff.  (I’m trying to add a new function every few weeks or so.)  In the next post, I’ll get into some of the details on how the library actually works.