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).

I thought it prudent to blog a bit about some of the technical books I’ve been reading of late so thus begins perhaps the first of several posts about my library:

I ordered Prototype and script.aculo.us by Christophe Porteneuve the other week directly from the publisher, the well-known Pragmatic Programmers. I highly recommend buying books directly from them as you can get a PDF copy for very little extra money. Who likes lugging around books all the time, anyway?

This book is a comprehensive guide to Prototype and script.aculo.us and covers both libraries from beginning to end. You need only have a basic understanding of JavaScript to dive in—which was perfect for me as I’m really weak on JS. The readability of this volume is perhaps its best quality. I can literally sit in bed and read this book cover to cover without feeling like I need to have my laptop by my side. It seems to have a larger ratio of words to code and the writing style of Porteneuve is refreshingly casual, friendly, and funny.

The book itself is not huge, about 400 pages, but its content that counts. And, thankfully, it doesn’t waste trees with pages and pages of reprinted documentation. Oh how I can’t stand buying a big fat technical book for $60, only to discover that half of its pages are reformatted documentation that’s freely available!

The “Bungee Book”, as the author refers to it, (Sidebar: Is this going to be a thing now? Every PragProg book has to be nicked named after its cover picture? Who gets to pick the cover pictures?), is a great read and I highly recommend it for your bookshelf.

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.