Tuesday, May 13, 2014

Every year my review forms are dominated by a gapping void that's the "certifications" checkbox.  Time in the IT world flows differently--many moons passed, mountains were worn to pebbles, and those blown to dust.  As MCTS SP07 became MCTS SP10, my manager's hopeful look turned quizzical, then accusatory. What man would so wantonly forsake his yearly goals?  Oathbreaker, they call me.

Now that MCTS has been replaced by MCSD altogether, the time has come to get off my butt. This is the year I shall be certified.  Better years late than never, right?

I will update this post with tips and resources for the four MCSD SharePoint exams as I go through them.

Monday, May 12, 2014

I ran into a strange issue today when using the SharePoint 2013 REST API for Lists with Managed Metadata columns.  For a multi-select taxonomy column, the List service returns Label text as expected.  But if you change that same column to single-select, suddenly an ID is returned in the Label field!

For instance, consider an Orders list with a Product multi-select taxonomy field.  I run the following REST query to dump all the list items:

  http://sharepointificate/_api/web/Lists/GetByTitle('Orders')/Items

All is good and the Product label text is returned:

Now if I just change Product to single-select and run that same query, the friendly label is gone!  This has to be a bug.  Yes, YOU, Microsoft.  I'm talking to you!

 

Luckily, there is a workaround. The Taxonomy label is correctly returned when we use a CAML query to retrieve the list items.  Erik C. Jordan's answer on this MSDN thread reveals a way to use CAML against the REST API.  This guy must be some kind of SP savant, because I can find absolutely no other documentation on this method—but it works: 

/GetByTitle('Orders')/GetItems(query=@v1)?@v1={'ViewXml':'<View><Query></Query></View>'}

A couple things to note:

1. GetItems is a POST operation.  The query above will not work when run from your browser's address bar, which performs a GET.  You need a tool like Fiddler to send a POST message to the REST endpoint.  More likely, you'll be doing a jQuery ajax call like the example below.
2. An X-RequestDigest message header is required for POST operations against the REST API.  Its value differs between environments and apps.  If this header is missing or incorrect, the server will return a 403 Forbidden error.  When executing within a SharePoint-hosted or on-premise context, it should be available on the page itself, and you can grab it with $("#__REQUESTDIGEST").val().  For other contexts, you'll have to retrieve the value like this MSDN article describes.

The complete Ajax call:

$.ajax({
    url: "http://sharepointificate/_api/web/Lists/GetByTitle('Orders')/GetItems(query=@v1)?@v1={'ViewXml':'<View><Query></Query></View>'}",

    type: "POST",

    headers: {
        "Accept": "application/json;odata=verbose",
        "X-RequestDigest": $("#__REQUESTDIGEST").val()
    },

    success: function (data, textStatus, jqXHR) {
        console.log(data.d.results[0].Product.Label);
    },

    error: function (jqXHR, textStatus, errorThrown) {
        console.dir(jqXHR);
    }
});

Thursday, May 08, 2014

I discovered something beautiful and wonderous today. It's possible in Powershell to use a variable directly as a property name!  For instance:

Windows PowerShell
Copyright (C) 2012 Microsoft Corporation. All rights reserved.

PS C:\> $d = Get-Date
PS C:\>
PS C:\> $prop = "DayOfWeek"
PS C:\>
PS C:\> $d.$prop
Thursday
PS C:\>

Mind blown.

Monday, May 05, 2014

jQuery Promises have been around for a while, but I've always slinked away tail between my legs at the mere mention of them. Running might have attracted the beast's attention. Alas, my new project uses Promises religiously. They are actually nifty constructs once you wrap your head around them.  I had to stew and mull for about a week before I could grasp the difference Promises and Deferred (I know, what a scrub)

This post is for anyone specifically wondering about Promises vs Deferred.  I'm not going to talk about Promises in general--there are already a ton of good articles on that topic.

There is really nothing special about Promises and Deferred--they are both plain ol' JavaScript objects.  Every Deferred object has a corresponding Promise object.  The Promise is essentially a copy of the Deferred with limited functionality.

When you are running an async operation, you create a Deferred.  You can then use it to attach handlers, and more importantly, Resolve or Reject when the operation completes.  In the meantime, you get the Deferred's corresponding Promise and return that to your caller.

As the caller, you get back a Promise object with which you can also attach handlers. The difference is that you can NOT trigger those handlers by calling Resolve or Reject.  This makes sense, because the caller wouldn't / shouldn't know about the async operation and when it completes.