SPServices v0.7.1ALPHA13 Available for Testing

Faster and more furious, that’s what I always aim for.


I’ve been working hard on this next release of SPServices. I’ve been lucky to have some down time between projects to do it. Yes, I’m happy to have the gap so that I can do more and do it better; I’ve been able to make even more significant improvements because I’ve has the focused time. It’s a great feeling to look at my old code and know that I can do a lot better now. This version of SPServices is going to be leaner and faster than ever before. As I tweeted the other day:

Alpha13, which I just posted is, I think, a good one to think of as RC1. Before I get too busy again with client work, I want to get it out there for some of you to test. If you are an SPServices user and can do some testing, especially regression testing, I’d really appreciate it.

There’s also some new stuff that I’ve built into the last few alphas:

  • Better error messages for SPCascadeDropdowns, SPDisplayRelatedInfo, and SPFilterDropdown. If you have debug mode on and the listName is incorrect, you’ll get a clearer message.
  • Improvements to the new SPXmlToJson function. All of the documented options now work as advertised and I’ve optimized the code quite a bit.
  • SPCascadeDropdowns and SPDisplayRelatedInfo now have a matchOnId option. If matchOnId is set to true, the ID of the Lookup column is used rather than the text value. This can be handy where the same text value means different things, like the place-name of Springfield, which can be found in 34 of the US States. By default the behavior of the function remains the same, of course.
  • New operations: Lists.ApplyContentTypeToList, Lists.CreateContentType, Lists.DeleteContentType, Lists.GetListItemChanges, Lists.UndoCheckOut, Lists.UpdateContentType, SiteData.GetWeb
  • Numerous (and I do mean numerous) improvements for efficiency.

Enjoy, and let me know if you have a chance to try it out.


Finding the Distribution of Column Types in a SharePoint List with SPServices

I just went through a little exercise that was simple, but fun, and I thought I’d share. As part of building my new SPXmlToJson function for SPServices, I wanted to spin through some of my lists to see what the various types of columns were and count the occurrences. Sure, I could have probably just looked in the SDK somewhere for the exhaustive list, but I though it would be a useful exercise to code something. The idea was to call GetList on a particular list, go through all of the columns in the results, and list out the number of times each column type shows up.

Since I am building a function to emit JSON, knowing what type of objects I need to create is important. Each column has a type, of course, which you select when you create the column. In the UI, the column types are things like “Single line of text”, “Choice”, or “Lookup”, as you’re probably used to seeing:

Create a List Column - Column TypesHowever, those aren’t the values that SharePoint stores in the list settings. If you work with the SharePoint Object Model with managed code, you’re used to seeing SPFieldType (yup, that link is where I could have gone to see the full list without resorting to my code).

SPFieldType in the SharePoint SDK

In the Web Services (at least GetList), we see an attribute simply named “Type” for each “Field”. Yes, fields are columns. Isn’t it grand how inconsistent some of the naming in SharePoint is?

Here’s the script I ended up with.  Since I’m focused on JSON, I wanted to play around with the various options for storing the data. I ended up with an array of typeName/typeCount values, which I could then sort in various ways. My first cut was to sort the types alphabetically and show them as simple list bullets.

  operation: "GetList",
  listName: "Sales Opportunities",
  completefunc: function (xData, Status) {

    var types = [];
    $(xData.responseXML).find("Fields > Field").each(function() {

      // If we already have this type in the array, increment the count...
      var match = false;
        for(i = 0; i < types.length; i++) {
          if(types[i].typeName === $(this).attr("Type")) {
            // No need to loop further
            match = true;

      // ...otherwise, add it to the array with a count of 1
      if(!match) {
        var thisType = {typeName: $(this).attr("Type"), typeCount: 1};

    types.sort(function(a, b){
      var typeA = a.typeName.toLowerCase(), typeB = b.typeName.toLowerCase();
      // We want to sort the type strings, ascending
      if (typeA < typeB) return -1;
      if (typeA > typeB) return 1;
      // If they are equal, return 0 (no sorting)
      return 0;

    var out = "<ul>";
    for(i=0; i < types.length; i++) {
      out += "<li>" + types[i].typeName + " = " + types[i].typeCount + "</li>";
    out += "</ul>";

    $(divId).html("").append("<b>This is the output from the GetList operation:</b>" + out);

What I ended up with is something like this:

Column Types Sorted AlphabeticallyTo see the column type sorted by number of occurrences, I simply changed the sort function to this:

types.sort(function(a, b){
  // To sort descending, subtract a from b; ascending would be the reverse
  return b.typeCount - a.typeCount;

This gave me output like this:

Column Types Sorted by Number of OccurencesSince I’ve found the SDK page for SPFieldType, this is throwaway code, but it’s not throwaway learning. It’s a little snippet of script that taught me a few things about formatting data for working storage on the client in script and also showed me what the internal types were for the columns which I use most often in my testing for SPServices. Note that while I’m using SPServices, and therefore jQuery, most of the heavy lifting in my script is plain old JavaScript.