has_many :thoughts

I just found this lovely tid-bit of information in the ActionController::AbstractRequest class…

# Returns true if the request's "X-Requested-With" header contains
# "XMLHttpRequest". (The Prototype Javascript library sends this header with
# every Ajax request.)
def xml_http_request?
    !(@env['HTTP_X_REQUESTED_WITH'] !~ /XMLHttpRequest/i)
end
alias xhr? :xml_http_request?

Mental note for later: Make sure to set this header when using jQuery in future projects…. Not sure if jQuery does this already (probably not).

Parts of an upcoming project make calls out to an external service that can take several seconds to respond. As everyone knows, the attention span of the average idiot web surfer is closer to a few nano-seconds. And so, we use AJAX loading indicator animated gifs to show the user something is happening.

However, several pages perform this call on their initial load. So an AJAX loading indicator won’t do the trick—the indicator has to appear on the preceding page in the navigation process. And so, we created some Javascript that would simply unhide an animated gift next to a “Next Step” button when the button was clicked. This provides some feedback to user that the next page is loading. (The user could, of course, note the status of their own browser’s load-indicator, but I suspected many wouldn’t.)

This seemed to be working great until solid IE testing began. We soon discovered that as soon as navigation away from the current page has begun, IE stops all animated gifs. The result is a rather unhelpful seized-up spinner-gif that actually makes the user think something went wrong.

So instead of an animated gif, we now use the lovely effect features of script.aculo.us to fade a non-animated hourglass icon in and out when the button is clicked. Some JS like this…

Effect.Pulsate(icon, {
    duration: 100, 
    pulses: 95
});

...results in something like this:

The net result is the same: the user knows something is happening behind the scenes. But now, at least, it plays nice with IE. Seems that IE lets JS effects like this go on even after the call to the next page has begun.

In retrospect, it might been best to ensure that our page loads didn’t call the external service directly. But rather, load the next page rapidly and then made an AJAX call out to trigger the slower service. That way, we could have avoided these issues all together and used the traditional, in-page AJAX loading animated gifs.

Oh well. There’s always version 2.0.

Londoner Dan Webb, creator of the UJS4Rails.com website with plugins for Unobtrusive Javascript, presented about some tips and tricks for dealing with Javascript in Rails. He revealed that he’s not maintaining the Unobtrusive Javascript plugin but instead has been focusing his free cycles on an extension to Prototype called LowPro.

I actually had a bit of a hard time following much of the technical nitty gritty of this talk. Mostly because my Javascript skillz are lacking. But also because it was packed as hell and pretty uncomfortable to sit still.

Dan did stress that we should all do a better job of making sure our Rails apps at least still function when Javascript is not available. He presented an example of an acquaintance who was unable to use any site using the standard AJAX frameworks because they all used the eval function of Javascript which the corporate security nazis frown upon.

His recommendation was to think about how your app can work, albeit with reduced functionality, when Javascript is not available to the user. One should build their app without any AJAXishy features at first, and then layer on the Javascript, AJAX, and “interface sheen” as he called it. I agree, although I think a decision about how much functionality to provide fo non-javascript-enabled browsers needs to be carefully considered in the context of the project at hand.