Getting Mileage Out of the Client-Side Object Model, Part 1

Background:

The union of JavaScript and SharePoint got off on uneasy footing. Microsoft designed the early versions of SharePoint to work with the venerable (and notoriously quirky) Internet Explorer, complete with its proprietary ActiveX controls and its alternative implementations of JavaScript and CSS behavior. Even in SharePoint 2010 you will encounter dramatic differences in the user experience between Internet Explorer and other browsers. For example, Silverlight (Microsoft's .NET-based Flash substitute) powers the list creation menu and media player web part, while an Internet Explorer-specific ActiveX add-on powers the direct Office integration that occurs when you choose to edit a document in Excel or Word (although a similar add-on is available for Firefox).

But times change. As if to atone for the sins of IE6, the latest versions of Internet Explorer in many ways boast greater adherence to W3C standards for CSS and HTML 5 than competitors Chrome, Firefox, and Safari. JavaScript monkeys can finally attach events to DOM objects the same way for all modern browsers. Meanwhile, HTML 5 and JavaScript are baked into Windows 8 as first-class citizens for developing apps. Recent issues of Microsoft's MSDN Magazine have highlighted how you can use common JavaScript libraries like jQuery, Knockout, and Modernizr to speed up the development of useful and user-friendly apps.

But that's getting ahead of ourselves... Let's get back to SharePoint!

A Brief History of SharePoint's Client-Side Access Points

SharePoint 2007 exposed a set of web services that could be wrangled into doing client-side operations against SharePoint content; in fact, Microsoft's own SharePoint Designer tool utilized these web services to perform its dubious magic. The respectable jQuery-based SPServices JavaScript library (notably not written by Microsoft) was developed as a wrapper for the web service calls, saving client-side developers the headaches of composing and executing their own SOAP messages.

SharePoint 2010 introduced more lightweight, more easily consumed RESTful web services for most list operations, providing replacements for the majority of the old .asmx web services.

Building on that RESTful foundation, SharePoint 2010 also introduced a new Client Side Object Model (CSOM) for both .NET (either desktop apps or browser-based Silverlight apps) and JavaScript.

So can we throw out all those books on SOAP web services? Well, not quite. The CSOM has its own limitations, notably in that it cannot be used to share data between site collections, in which case we still need to crack out our SOAP and hit up the ol' .asmx web services.

Drawbacks of Using the XLST List View Web Part for Presentation

Where the JavaScript Client Side Object Model really shines is the manipulation and presentation of list data.

In SharePoint 2007, this realm was dominated by the dataview web part in all its convoluted custom XSL glory. While SharePoint 2010's comparable XSLT list view web part is much cleaner than the old dataview, and delightfully easy to manipulate via SharePoint Designer (conditional formatting and parameters are my personal favorites), it has its shortcomings.

For example, it only exposes certain segments of XSLT templates for you to manipulate after you change them through the design interface--my trick was always to select the text in a column I wanted to manipulate through the design view and make it bold with Ctrl+B, which caused the corresponding template section to spring from nothingness into the code view, dutifully enclosed in <strong> tags.

The XSLT list view web part has its benefits:

  • It is great for displaying list data in a table consistent with the SharePoint user interface
  • It supports sorting/filtering on column headings
  • It supports list/item context menus in the ribbon
  • Templates are rendered quickly and list content loads on the page almost simultaneously with other page content
  • The most useful features it offers can be added and configured without ever touching the underlying XSLT:
    1. parameters
    2. filters
    3. web part connections
    4. conditional formatting

But as soon as you wanted to present list-based information in a non-tabular format, you would end up rewriting the XSLT from scratch. Add to this the dependency on SharePoint Designer 2010 as a development interface--with its rendering delays and occasional application crashes--and alternatives look more and more appealing.

More Syntax to Learn?

At this point I could mention that knowledge of JavaScript is not only more common but also more broadly useful than knowledge of XSL/XSLT in web development, and increasingly so.

SharePoint developers and administrators already have an abundance of languages and technologies to learn as it is--from the basic HTML and CSS, to PowerShell, the ins and outs of the SharePoint object model with its infamously leaky COM components, and of course everyone's favorite Collaborative Application Markup Language (CAML).

Throw some SOAP/XML expertise into the mix if you want to do cross site-collection queries, SQL if you want to track down mysterious errors in the user info table, and even obscure STSADM.EXE commands for various administrative tasks (despite assurances that it would be supplanted by PowerShell cmdlets).

Somewhere along the way I learned how to form beautiful LDAP queries too. But this is a tangent.

Learning XSLT is certainly useful, especially if you want to make your own rendering templates, but I personally find the depth of nested templates in the XSLT web part intimidating, and often find myself searching the web for XSL resources if I need to make a seemingly minor change to a view.

Drawbacks Of Using The CSOM for Presentation

I've ripped on the poor XSLT list view web part long enough. Honestly, there are also trade-offs to using the JavaScript-based Client Object Model in its place.

  • The client services can only be called after Microsoft's sp.js library has been loaded by the browser, so it's already guaranteed that your script won't be able to retrieve and display information as promptly as the XSLT list view. Go overboard on CSOM and your users are going to get pretty tired of spinning circles and "Loading" flyouts.
  • The objects and methods of the CSOM are a language of their own, heavily influenced by the server-side object model (we'll see our old friend the CAML query again) but tempered by inconsistent attempts to adhere to common JavaScript conventions (such as camel cased variable names and get and set accessors/mutators). It is further complicated by asynchronous methods and objects. Wasn't I just complaining about the plurality of languages and technologies SharePoint folks need to know?
  • The mappings between the CSOM and the server object model are not complete. For example, the CSOM is incapable of meaningful interaction with SharePoint 2010's exciting managed metadata service, though this has been remedied for the SharePoint 2013 implementation.

Ultimately, the flexibility of the JavaScript CSOM over the alternatives means it's worth the minor headaches. It takes some getting used to, and it pays to have examples to start from, but you'll soon find yourself recognizing situations where a little script can go a long way, whether it's filtering a list on multiple multi-choice field values at once or manipulating a default form on the fly.

In my next post I'll provide an example from my own recent experience.

Add comment

biuquote
  • Comment
  • Preview
Loading

Recent Comments

Comment RSS

Post History

<<  August 2018  >>
MoTuWeThFrSaSu
303112345
6789101112
13141516171819
20212223242526
272829303112
3456789

View posts in large calendar