jQuery UI: Remote Accordion Content

The jQuery UI tabs widget supports loading tab content from remote sources out of the box. The accordion widget, however, does not. Which is unfortunate because there are advantages to deferring the loading of content till the section is expanded. Your application may have an accordion for several seldom, if ever, sections that are opening. That's a big cost savings, so let's see how we can implement such a capability.

Idle Ajax Polling

Web applications like to fetch new data resources in the background.  Javascript toolkits — in conjunction with Ajax browser technologies — allow the user interface to refresh application data asynchronously.  There is no need to reload the page.  jQuery has a suite of useful Ajax utilities for fetching new data and parsing it.  This frees up the user interface to notify the application server when it needs more data — perhaps on a recurring basis — each request polling for fresh information.  But should this sequence use a fire and forget approach?

Seeking new data
Web application user interfaces are different from their more traditional desktop counterparts.  With a desktop user interface, it's easy to listen for changes in data — changes the user is interested in.  For instance, one pattern might be to have your widgets act as observers on particular pieces of application data.  When the data changes, the widget is notified and can thus make the appropriate visual changes.

There is no need for desktop user interface libraries to poll for changes in the underlying application code — the application can notify the user interface.  However, with user interfaces that run inside a web browser, data is often stored on the remote application server — so it needs to stay informed.  This is easy enough for the user — they simply need to hit the refresh button and voila — up-to-date information.

The emergence of Ajax in Javascript user interfaces revealed some inefficiencies with the refresh button.  First of all, hitting refresh is going to retrieve a new copy of the entire web page — this is wasteful as we've already got the user interface — desktop applications aren't going to rebuild the entire screen when changes in data occur.  Second, you'll seldom find refresh buttons inside desktop user interfaces — the data finds the user.  In other words — web user interfaces should be automatically populated with changes in data.

Since it's difficult to have the application server notify the user interface about these changes — the Javascript needs to poll for data changes in the background.  When new data is detected, the interface is updated accordingly.  One potential issue with implementing a polling loop is how do we ensure minimal resource usage?  After all, each poll needs to travel through the network.

Idle windows
One approach to saving on resources with a polling Javascript user interface is to detect when the browser window is idle.  An idle browser window is one that is open with the user interface loaded, but not in focus on the user's desktop.  For example, the user might switch tabs or switch to another desktop window entirely.  We can attempt to capture these events and modify our polling logic fittingly.

Here is a simplified demo using jQuery that shows how we might use the focus and blur events to start and stop our polling loop respectively.

var poller;
$(document).ready(function(){
    function poll(){
        $('body').append($('<p></p>')
                 .html('Polled.'));
        poller = setTimeout(poll, 3000);
    }
    $(window).focus(function(event){
        $('body').append($('<p></p>')
                 .html('Active.  Starting poll...'));
        poll();
    });
    $(window).blur(function(event){
        $('body').append($('<p></p>')
                 .html('Idle.  Stopping poll...'));
        clearTimeout(poller);
    });
});

Resources saved
In the example above, we're polling (not actually polling anything, but you can see where the real Ajax code would go) every three seconds.  When the window becomes idle, we stop polling.  This signifies that the user is no longer interested in receiving new data from the application server.

By not polling for new data, we're not consuming network bandwidth.  We're also not consuming CPU cycles on the client when new data arrives.  This is a win for both the client and the web application.

Handling Callback Variables

With Javascript applications that make asynchronous Ajax requests, does it make sense to store a global variable that indicates the callback that should be executed? That is, depending on the current state of the application, a different callback function may need to execute for the same API call. Should a global variable be set before the request is made and checked each time by the response?

That doesn't feel right to me. Neither does sending application data along with the API request just to be used by the callback. That would mean sending application state to the server which isn't a good thing as far as I'm concerned.

I like the idea of listening for certain events that the callback might emit during execution. The callback might emit a certain type of event each time it is run. The events are always emitted but the application may not always be listening. When the application is in a certain state, it will be listening. The handlers of these events could be considered secondary callbacks.

When To Use Ajax

Take a look around the web today. You'll be hard-pressed to find many interfaces that don't incorporate at least some aspect of ajax. The term ajax has grown to mean more than just asynchronous javascript API requests, although that is a huge part of it.

Ajax can add a new level of interactivity to a web application user interface. This can be done by making changes to an existing interface or by implementing the principles of ajax straight from the get go. Typically, however, you aren't going to want to use asynchronous API calls from an existing javascript application that doesn't already. Especially not if it is stable. There are other aspects of the ajax style that can still be applied in these scenarios.

Many javascript toolkits are in existence today and most provide widget support in one form or another. Widgets are really no different from those found in APIs for desktop environments. The only obvious difference is that these widgets are drawn in the browser using javascript and CSS. Developers get a few things for free when implementing the widgets found in javascript toolkits. First, you get the free design, which, isn't easy to do. Especially if themes are of concern. Second, many of these widgets are configurable and can offer the end user subtle behavioral interaction improvements. The overall user interface has been made "smoother".

One of the great things about the web is addressability. Opponents of ajax say that ajax applications take this attribute away. And, in most cases, they are right because applications that use asynchronous javascript API calls exclusively, have no URIs that users can see and manipulate. They can't copy and paste links. This is one of the key reasons why the web is the size that it is today.

There is, however, a middle ground. Just because a web application implements ideas found in ajax doesn't mean that it can't have useful URIs. Even if the set of useful URIs is a small one, it is still useful to have for the user's sake. Obviously, these URIs become less important if the web application is an internal application that doesn't live on the web.

Django Ajax Response

The Django Python web application framework is capable of many types of data serialization.  Be it, XML, or JSON, The built-in Django serialize() function can handle it.  The transformation typically starts with a Python dictionary or list but can also handle instances of user-defined types.  The end result is always a string.  The string is of course desired because that is what will be passed along inside the HTTP response.  It is nice to have this functionality, but what is it used for?  Why not just use standard templates with template variables and let the view render it for the client?  The main reason is that more and more non-browser clients are being used with web applications.  Even if the client is a web browser, there is a good chance that the request is coming from an ajax application and they don't always like HTML responses.  Most prefer the JSON format.

There is, however, a good chance that more than one format is going to be necessary for the same data set.  For instance, I might have a standard Python dictionary that I want to return to the client.  Depending on who the client is, that same data is going to be rendered differently.  This is so that the client can understand the response.  Say, for instance, that the client was a javascript application.  This client could, potentially, have the ability to selectively handle different response formats that server returns to it.  This responsibility shouldn't really be left to the client application.  It would be nice if the Django application could automatically determine if a javascript application is requesting the data instead of a standard web request.  Thankfully, Django can do this without much developer intervention.

Django HTTP request instances can determine if the request came from an ajax application.  Django does this under the hood by examining the HTTP headers.  As is illustrated by the following example, simple scenarios like this one can be implemented with a single controller.

#Example; Django Ajax response.

#Import Django components.
from django.http import HttpResponse
from django.template import Context, Template
from django.core.serializers import serialize

#Initialize the test data object.
data_obj={"first_name":"First Name", "last_name":"Last Name"}

#The test view.
def index(request):
    #Check if this is an ajax request.
    if request.is_ajax():

        #Set the result to serialized JSON data.
        result=serialize("json", data_obj)

    else:
        #Create a context object from the test data.
        context_obj=Context(data_obj)
        
        #Create a test template string.
        template_str="""<b>first_name</b>: {{first_name}}<br/>
                        <b>last_name</b>:  {{last_name}}"""
                        
        #Set the result to the rendered HTML.
        result=Template(template_str).render(context_obj)

    #Return the response.
    return HttpResponse(result)

Addressability Lost Within The Realm Of Ajax

With RESTful APIs and applications, and with HTTP in general, addressability plays a huge role. With web applications that project an Ajax user interface, this addressability is typically gone. There is no notion of URI as far as the end user is concerned. This is because Ajax web applications often have a single URI; the application itself. From this point forward, the end user navigates through the various application states while all the addressable URIs are contacted beneath the fancy Ajax interfaces. If you are an end user using these types of applications, do you necessarily care? That would depend what you are using the application for and the type of user you are. For most end users, if the use interface is well designed, the addressability of the resources involved with the application are a non-issue. Even developers, the type one would think would be interested in the underlying application data, might be too enthralled with how useful the user interface is. If the user interface of an Ajax web application is poorly designed, things change. The data at the other end of the URI suddenly becomes much more interesting.

In more traditional web applications, the ones without the fancy asynchronous javascript toolkits, the URI of almost every resource is accessible from the address bar in the web browser. This is obviously the benefit to having addressable resources in a web application. The URIs are immediately apparent to the end user via the web browser address bar. With Ajax web applications, end users cannot point there web browser to a specific URI and expect the application to behave accordingly. This, I find, to be one of the more annoying drawbacks to using Ajax web applications. Although the user experience of Ajax web applications is improving at an ever increasing rate, the sacrifice of addressability, a powerful concept, has to be made.

But does addressability really need to be lost completely in Ajax web applications? Just because the URI isn't in its' normal location, the web browser address bar, doesn't mean the end user can't know about it. In fact, many web applications that provide an Ajax user interface will also provide a public RESTful API used by that interface, complete with documentation. However, this doesn't solve the problem of the end user that doesn't care about API documentation and just wants page X of the application to appear when they point their web browser to URI Y. I think something like this could potentially work. There would have to be two separate RESTful APIs; one for the application resource data, and one for the user interface. The user interface would interest the end users because they could use these URIs to point the web browser to a specific application state. These user interface application URIs wouldn't even need to be reflected in the web browser address bar. As long as the current user interface application state is advertised somewhere in the user interface, it could work. And it would be incredibly useful.