Props to this guy’s post.
Some parts are kind of confusing, but it’s a testatment to how much code he posts that I didn’t even realize he was French until I sat down to write this post and read it more carefully — he communicated mostly in code.
He gives a good Rails application.js file for you to start out with — basically it provides a bunch of handles for things you want to remote w/ XHR. They use the new-ish jQuery method unbind to make sure that regular events on items designated as AJAX get overriden. Pretty slick and a good way to think of jQuery’s usage in an app context. So far, I hadn’t really used it for AJAX beyond a thing I wrote to enable cross-domain MX record validation.
Example: remote links
Rails provides the link_to_remote helper to let you create links that will trigger a GET over XHR. This application.js defines a jQuery function for that and then binds it to a certain class of links — “get”:
1 2 3 4 5 6 7 8 | jQuery.fn.getWithAjax = function() { this.unbind('click', false); this.click(function() { $.get($(this).attr("href"), $(this).serialize(), null, "script"); return false; }) return this; }; |
Which is then set with this:
1 | $('a.get').getWithAjax(); |
Now any anchor with class “get” on it will result in a remote call to the URL in that anchor’s href. Combined with a respond_to block in your controller to handle Javascript and a Javascript template file, you can use links like this to (for instance) load ActiveRecord objects into a page using AJAX. Instead of “show.erb.html” your controller’s show method is handled by “show.js.erb”. This block in the show method of the controller ensures that it is activated correctly:
1 2 3 4 | respond_to do |format| format.html format.js { render :layout => false } end |
Because the call came in over XHR, the controller sees the format as being JS and responds with the instructions set in the block passed to format.js. Rendering without layout ensures that nothing but the rendered data plus the template is returned.
Notice that the AJAX call in the above snippet from application.js uses the “script” datatype. This specifies that the returned data should be evaluated as Javascript, which is what we want, because the returned data includes the jQuery-based instructions we have inside show.js.erb, and those need to get evaluated (not just displayed) in order for the page to look right.
An aside: One thing that this makes me think about a lot is how important visual design is when you’re developing an application. Your design has to correspond concretely to a DOM with all sorts of manipulative handles (ids and classes) and all sorts of custom functions built to do various things to/with them. You’d damn well better draw a decent picture of this and give the elements of it some good names that make sense. In fact, I think a lot of the true work in programming involves drawing pictures (I still model some embarrassingly simple relationships with pencil and paper), but that might just be the way that my brain works.
Anywho, I took the above application.js and used it as the basis for a conversion from RJS to jQuery in a Rails app I’m working on. I’ll probably end up adding quite a bit to his stuff as I go, but having this file around made starting the transition process a lot easier.
I expect to do some more posts on the conversion as I go, since I haven’t found a whole lot of stuff yet that’s oriented toward “strategies for using jQuery with Rails” and wasn’t written in 2007. RJS kept me from dealing w/ JS directly as a major component of my app, but those days are over now that I’m committed to unobtrusive JS via jQuery, and a more thought-out approach will be necessary.
Copyright © 2010 Catapult Creative - info(at)catapult(hyphen)creative(dot)com - Powered by