Tuesday, 4 January 2011

SP2010 AJAX part 7: Useful tools when building AJAX applications

  1. Boiling jQuery down to the essentials (technique)
  2. Using the JavaScript Client OM to work with lists (technique)
  3. Using jQuery AJAX with a HTTP handler (technique)
  4. Returning JSON from a HTTP handler (technique)
  5. Enable Intellisense for Client OM and jQuery (tip)
  6. Debugging jQuery/JavaScript (tip)
  7. Useful tools when building AJAX applications (tip) - this article
  8. Migrating existing applications to jQuery/AJAX

In this ‘quick tip’ article I want to show you my pick of the tools you might use when building AJAX applications on top of SharePoint 2010. For the most part, the ‘core’ tool used is the debugger which, as we discussed last time, could be Firefox/Firebug or the IE Developer Tools depending on your preference – the tools here take this further. In fact they’re not specific to SharePoint in any way, and Elijah Manor has a more comprehensive drilldown in his Debugging jQuery article I recommended last time – I’m merely adding my view as what particularly helped me on my journey. And since my analytics tell me that (at the time of writing) only 3% of folks who read that article followed the link, I may as well do my bit to spread this information.

All of the tools recommended here are Firebug add-ons (itself an add-on for Firefox) – arguably backing up the view that Firefox currently offers a superior JavaScript developing/debugging experience to IE.

Tool #1 – Firefinder

Firefinder specializes in helping you debug jQuery selectors – this is often necessary as a first step to finding out why your button click event (or similar) isn’t happening. Firefinder is specifically capable of working with selectors which are valid CSS selectors (remember that jQuery uses CSS selectors but adds some of it’s own), but for much of the time this is all you need. In addition, it also has XPATH capability which could be handy if you’re using the jQuery XPATH plugin (or otherwise just working with XPATH over XHTML). Firefinder appears as a tab in Firebug – simply enter the ID/CSS class/XPATH of the element you’re trying to select, and jQuery will highlight any matches with a dotted red border:

Selecting by CSS class:

FirefinderByCssClass

Selecting by HTML ID:

FirefinderByID

The ‘Inspect’ link is particularly useful as it takes you directly to that place in Firebug’s HTML view:

FirefinderInspectHtml

Tool #2 – FireQuery

Continuing the example of establishing why a jQuery event isn’t firing, FireQuery is awesome for showing you which events have been bound to which HTML elements. Consider that the unobtrusive nature of jQuery means that events are bound separately and your HTML is completely ‘pure’ with no nasty onclick attributes to ruin the separation of presentation and behavioural logic. Of course, this does mean that you cannot natively ‘see’ if a control has a jQuery event attached. Enter FireQuery – it injects text into the HTML view in Firebug to show you where your events are on the page. Here I can see that the button I’m looking at has a click event bound to it:

FireQueryShowingEvents

That’s it for today. Again, I highly recommend you check out Elijah Manor’s How to Debug your jQuery code article.

Next time: Migrating existing applications to jQuery/AJAX

Wednesday, 22 December 2010

SP2010 AJAX part 6: Debugging jQuery/JavaScript

  1. Boiling jQuery down to the essentials (technique)
  2. Using the JavaScript Client OM to work with lists (technique)
  3. Using jQuery AJAX with a HTTP handler (technique)
  4. Returning JSON from a HTTP handler (technique)
  5. Enable Intellisense for Client OM and jQuery (tip)
  6. Debugging jQuery/JavaScript (tip) - this article
  7. Useful tools when building AJAX applications (tip)
  8. Migrating existing applications to jQuery/AJAX

In this ‘quick tip’ article I want to quickly introduce how to debug AJAX-type applications, then point you to a more detailed ‘debugging JavaScript’ article which I really like. Although every developer is (should be) comfortable with debugging their server-side .Net code, the advent of JavaScript-heavy applications means that new debugging techniques must be learned. Debugging script is typically done outside Visual Studio and as I see it you have two main options:

  • Use the IE Developer Tools (separate install required for IE7) and debug with IE
  • Use Firefox and install the hugely popular Firebug add-in

In many respects, the JavaScript debugging experience is fairly similar – you first select which of the .js files linked to the page should be debugged, then find the place in the code to add the breakpoint. When the code runs, the debugger will stop and allow you to step through (F10)/step into (F11) and also see/amend local variables and see the call stack etc.

In IE: (click on the images to see clearer versions)

DebuggingWithIETools

In Firefox:

DebuggingWithFirebug

I think it’s a popular view that Firebug offers a better debugging experience than the IE tools – as the image shows, Firefox allows me to hover over a variable and see it’s value, and also gives me easy access to the ‘this’ variable in jQuery – neither of which the IE tools do. It’s possible to do many of the advanced debugging scenarios such as conditional breakpoints, set watch variables, and even break automatically on a JavaScript error. The ‘Console’ tab is also useful for analyzing the response over the wire from a HTTP module or the SharePoint Client OM – something you need to do frequently. Furthermore, as I showed in article 4, if the response is JSON then Firebug helps out by formatting the response into an expandable/collapsible view:

JsonInFirebug

I’m a huge fan of Firebug, and I highly recommend digging into the other areas of functionality such as the ‘Net’ tab for analysing page load times (something I discussed in my Checklist for Optimizing SharePoint Sites article a while back).

To delve more fully into JavaScript debugging, Elijah Manor’s How to Debug your JavaScript code article should be considered required reading.

Next time: Useful tools when building AJAX applications (tip)

Wednesday, 8 December 2010

SP2010 AJAX part 5 - Enable Intellisense for Client OM and jQuery

  1. Boiling jQuery down to the essentials (technique)
  2. Using the JavaScript Client OM to work with lists (technique)
  3. Using jQuery AJAX with a HTTP handler (technique)
  4. Returning JSON from a HTTP handler (technique)
  5. Enable Intellisense for Client OM and jQuery (tip) - this article
  6. Debugging jQuery/JavaScript (tip)
  7. Useful tools when building AJAX applications (tip)
  8. Migrating existing applications to jQuery/AJAX

This article marks a change in this series – whereas the previous four articles were detailed guides on key techniques, the next few are short and sweet tips which might be useful on the journey. Today we talk about Intellisense, specifically for JavaScript libraries a SharePoint developer may use such as jQuery or SharePoint 2010’s Client Object Model.

Although many developers put up without having Intellisense for such code (it’s not enabled by default), there’s no real reason not to enable it if you’re writing more than a couple of lines. Without it, you only get the less-than-useful default JavaScript Intellisense which looks like this:

DefaultJSIntellisense

Taking the Client OM as an example, here’s what proper Intellisense looks like when it’s enabled – that’s a long dropdown and trust me, you want it:

FullClientOMJSIntellisense

In terms of enabling it, there are a couple of variations depending on where you need the Intellisense, and whether we’re talking about jQuery or the Client OM. Let’s run through them.

Enabling Client OM Intellisense in a .js file

All you need for this is a couple of reference paths at the top of your .js file:

/// <reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\MicrosoftAjax.js" />
/// <reference path="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.debug.js" />

Sidenote: If you want Intellisense on other JS files, you’ll need to add corresponding references. For example, digging around finds a nice SP.XmlWriter class in SP.Core.js for building XML in JavaScript – you’ll get no Intellisense for this with the snippet above, but the appropriate reference to SP.Core.debug.js will fix that. I list which bits of the Client OM are in which JS file at the end of this article.

Enabling Client OM Intellisense in markup (.aspx/.ascx)

For a code in-front file (do people still call it that? :)), we need to add <script> tags as if we were adding a normal .js files to the page/control. Consider however, that SharePoint already takes care of ensuring the right JavaScript files are referenced on a page at runtime, and that by adding duplicate references we would cause problems. All that’s needed is an inline ASP.Net conditional statement which will be false at runtime (so that the contents aren’t processed), but which Visual Studio sees just fine at design-time (apologies for the color-coding here, the ASP.Net brackets would be bright yellow in Visual Studio):

<% if (false) { %>
<script type="text/javascript" src="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\MicrosoftAjax.js" ></script>
<script type="text/javascript" src="C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\SP.debug.js" ></script>
<% } %>


Enabling jQuery Intellisense in a .js file

Here, the process is slightly different - Visual Studio needs a special ‘vsdoc’ file which provides the jQuery documentation. This can be downloaded from the official jQuery site, look for the ‘Visual Studio’ link next to the actual jQuery release files – at the time of writing, the latest jQuery version with documentation is 1.4.1. In a JavaScript file we again need to use the reference tag, this time pointing to the vsdoc file (note by the way, that the path can be relative or absolute):

/// <reference path="jquery-1.4.1-vsdoc.js" />

Enabling jQuery Intellisense in markup (.aspx/.ascx)

You’re probably getting the idea by now, but actually there’s an extra consideration for this scenario. When a JavaScript file is referenced in markup, Visual Studio automatically looks for an associated vsdoc file in the same directory – if one is found, you’ll have Intellisense. So that’s great, all we need is a reference to our ‘real’ JS file (which we need for run-time anyway) – however, we’re unlikely to want to use an absolute path for that, meaning VS could have trouble resolving the location. In SharePoint-land for example, you’ll most likely want to refer to your JS file with a ‘LAYOUTS’ relative path such as ‘/_layouts/jquery-1.4.1.min.js’, but since the IIS website is unknown to VS there’s no Intellisense. To get the best of both worlds, I just combine the two references, like so:

<% if (false) { %>
<;script type="text/javascript" src="../jquery-1.4.1.min.js"></script>
<% } %>
<script type="text/javascript" src="/_layouts/jquery-1.4.1.min.js"></script>

Appendix - JavaScript Client OM files

Taken from http://msdn.microsoft.com/en-us/library/ee538253.aspx:


Namespace

ECMAScript File

CUI Namespace

CUI.js, SP.UI.Rte.js

CUI.Controls Namespace

CUI.js

CUI.Page Namespace

CUI.js, SP.UI.Rte.js

SP Namespace

SP.Core.js, SP.js, SP.Ribbon.js, SP.Runtime.js

SP.ListOperation Namespace

SP.Core.js

SP.Ribbon Namespace

SP.Ribbon.js

SP.Ribbon.PageState Namespace

SP.Ribbon.js

SP.UI Namespace

SP.Core.js, SP.js, SP.UI.Dialog.js

SP.Utilities Namespace

SP.Core.js, SP.js, SP.Exp.js

SP.WebParts Namespace

SP.js

SP.Workflow Namespace

SP.js


Next time: Debugging jQuery/JavaScript (tip)

Sunday, 21 November 2010

SP2010 AJAX part 4 – returning JSON from a HTTP handler

  1. Boiling jQuery down to the essentials (technique)
  2. Using the JavaScript Client OM to work with lists (technique)
  3. Using jQuery AJAX with a HTTP handler (technique)
  4. Returning JSON from a HTTP handler (technique) - this article
  5. Enable Intellisense for Client OM and jQuery (tip)
  6. Debugging jQuery/JavaScript (tip)
  7. Useful tools when building AJAX applications (tip)
  8. Migrating existing applications to jQuery/AJAX

In the last post in this series, we discussed using a HTTP handler with AJAX - a highly useful technique when building SharePoint (and plain .Net) applications which aren’t postback-heavy, and as I said I believe that’s the most important post in this series. In the example there, my HTTP handler returned a simple string saying “Returned from handler at “ + DateTime.Now() – strings are fine of course (and remember that the value returning by a HTTP handler is always a string, so we’re somewhat constrained by that) but often we want something a bit more structured. This could be for one of the following reasons:

  • You’re returning many small pieces of information from one call, and putting them in say, a separated string and then parsing on the client is, um, nasty
  • You already have an object in code on the server, and frankly it would be nice if you could just work with that on the client too

In such cases, using JSON as the format for your return data could be a good choice, and is indeed what Microsoft’s own Client OM uses. Even better, you don’t really need to know much about JSON and it’s extremely easy to use. Aside from the basic need to return structured data, some reasons why you might choose JSON (over XML for example) might be:

  • JSON is more compact than XML
  • JSON is (arguably) simpler to consume in your JavaScript than XML
  • JSON has some useful tooling support e.g. Firebug

JSON 101

JSON is JavaScript Object Notation, and is simply a format for describing name/value pairs. They can be nested too, which means it can represent reasonably complex objects - in the end it’s always one big string when it goes over the AJAX wire, but effectively it’s easy to work with at either end. To show what it looks like, consider a class like this:

public class Employee
{
    public int ID
    {
        get;
        set;
    }
 
    public string Name
    {
        get;
        set;
    }
 
    public Address HomeAddress
    {
        get;
        set;
    }
 
    public Salary Salary
    {
        get;
        set;
    }
}

An Employee instance represented as JSON would look like this:

{"ID":1,"Name":"Chris","HomeAddress":{"HouseNumber":55,"StreetName":"Acacia Avenue","City":"Birmingham","Postcode":"B26 8LM"},"Salary":{"Currency":"Sterling","Amount":100}}

Now clearly that looks like a horrible string to construct yourself, but of course since JSON is a common format  you don’t have to. In the same way that an object can be serialized to XML in .Net using the XmlSerializer class, you can do the same to JSON format using the JavaScriptSerializer class. To send our Employee data to the client so that the page can be updated (e.g. using the jQuery page manipulation techniques from part 1), we would use the JavaScriptSerializer class in our HTTP handler, like so:

public void ProcessRequest(HttpContext context)
{
    Employee emp = getEmployee();
 
    // serialize and send..
    JavaScriptSerializer serializer = new JavaScriptSerializer();
    StringBuilder sbJsonResults = new StringBuilder();
    serializer.Serialize(emp, sbJsonResults);
 
    context.Response.Clear();
    context.Response.ContentType = "application/json; charset=utf-8";
    context.Response.Write(sbJsonResults.ToString());
}

Note that I’m setting the MIME type of the response header to “application/json” – this enables your app and any tools to recognise the string as a JSON string, and thus potentially provide any JSON-specific support. I’ll show an example shortly of how Firebug uses this to help you see the JSON coming from the server.

Consuming JSON in JavaScript code

As we noted earlier, JSON is ideal when we are dealing with many small pieces of information, like all the properties of an Employee. In the image below, I have an area on the page with many DIVs and SPANs to present the information – these get populated when the AJAX call to the server completes:

 JsonResults
The HTML and jQuery code to join up with the server side looks like this:

<fieldset id="fldDemo1">
    <legend>HTTP handler which returns JSON</legend>
    <div id="jsonDemo1Row" class="demoRow">
            <div class="demoControls">
                <button id="btnDemo1" type="button">Call handler</button>
            </div>
            <div class="demoResults">
                <div><span class="employeeField">Employee name: </span><span id="empName" /></div>
                <div><span class="employeeField">Salary: </span></div>
                    <div><span class="employeeSubField">Amount: </span><span id="empSalaryAmount" /></div>
                    <div><span class="employeeSubField">Currency: </span><span id="empSalaryCurrency" /></div>
                <div><span class="employeeField">Address: </span></div>
                    <div><span class="employeeSubField">House number: </span><span id="empAddressHouseNumber" /></div>
                    <div><span class="employeeSubField">Street: </span><span id="empAddressStreet" /></div>
                    <div><span class="employeeSubField">City: </span><span id="empAddressCity" /></div>
                    <div><span class="employeeSubField">Postcode: </span><span id="empAddressPostcode" /></div>
            </div>
    </div>
</fieldset>
<script type="text/javascript">
    $('#btnDemo1').click(function () {
        $.getJSON('/_layouts/COB/DemoJsonHandler.json',
        function (data) {
         $('#empName').html(data.Name);
            $('#empSalaryAmount').html(data.Salary.Amount);
            $('#empSalaryCurrency').html(data.Salary.Currency);
            $('#empAddressHouseNumber').html(data.HomeAddress.HouseNumber);
            $('#empAddressStreet').html(data.HomeAddress.StreetName);
            $('#empAddressCity').html(data.HomeAddress.City);
            $('#empAddressPostcode').html(data.HomeAddress.Postcode);
        });
    });
</script>

A couple of things to note here:

  • The JSON value is passed to the success callback of the AJAX call as the data parameter.
  • I can just use dot notation to access a property as if I was in C#/VB.Net/whatever (e.g. data.Salary.Amount) – no dodgy parsing for each value (woohoo!).
    • However, don’t expect any Intellisense here! Currently there’s no way for the tools to infer members on JavaScript objects you create yourself (jQuery and the SharePoint Client OM do it by way of a special documentation file - the next article in this series shows how to enable Intellisense for those). Given the move away from .Net web forms apps towards AJAX however, I don’t doubt that VS2013 (or whatever) may well have this.
  • Notice that jQuery has a convenient $.getJSON() method when you know that the server call is going to be returning JSON.
    • This is just like the $.get()/$.post()/$.ajax() methods we’ve looked at previously in this series, but this method performs an additional step of parsing the response to check it’s valid JSON. This let’s you handle such an error in a nice way (though note you need to use $.ajaxError() or $.ajaxSetup() to do this, rather than a failure callback on this call). Although we wouldn’t necessarily expect this to happen when we’ve used the JsonSerializer to build the JSON in the first place, in any case it’s much better than getting an obscure lower down problem e.g. when trying to get a piece of data from the Employee object.
  • The extension of my handler is .json – it doesn’t have to be, but if you’re happy to have a web.config entry (see my last article, Using jQuery AJAX with a HTTP handler for more discussion around this) then you can deviate from the standard .ashx which .Net automatically hooks up for you.

Tool support for JSON

It might not be a life-changing thing, but something very popular with developers using JSON in this way is the ‘Console’ tab in Firebug (which I briefly showed in the last article). Importantly, it allows me to see the ‘raw’ response coming back from a web service or AJAX call from the client - in the case of JSON, this is of course somewhat difficult to decipher:

RawJsonInFirebug
However, in contrast to Fiddler or many other tools, Firebug (via the Console > JSON tab) allows you to see a nice ‘formatted’ view of your JSON object, and you can expand/contract complex properties to see their values - much easier to digest:

JsonInFirebug

Final note - alternatives to JSON

Of course, JSON won’t always be the answer to passing data between the server and the client – sometimes you’ll prefer to work with XML, so here’s a good tutorial on parsing XML with jQuery.


Next time: Enable Intellisense for Client OM and jQuery (tip)