In this pursuit I learned a few things. Firstly, plain old JQuery does not “do” UJS in the following sense: if you bind a behavior to an element (via a CSS selector), that binding will not be reapplied as the DOM is manipulated. For dynamic binding, or “live” binding that gets re-applied after every DOM update, you need Brandon Aaron’s livequery plugin for JQuery. Livequery is to JQuery as Dan Webb’s Low Pro is to Prototype — kind of. Difference being that livequery hooks each of JQuery’s DOM manipulation routines, whereas Low Pro hooks each of Prototype’s Ajax.Responders “onComplete” event — the event that happens when an XHR is complete.

What all this means is that you can use JQuery’s UJS (livequery) if you use JQuery for all your DOM manipulations, or you can use Prototypes UJS (Low Pro) if you use Prototype for all your Ajax calls. The unfortunate bit is that you cannot (yet) use livequery with Prototype Ajax calls, or Low Pro with JQuery DOM manipulations. Can’t we all just get along?

I wonder if a UJS package could remain stack agnostic. I think livequery is on to something by hooking DOM manipulation routines. That seems more robust (if potentially less performant) than hooking the Ajax returns. By hooking DOM manipulation it seems that you’ve plugged more holes and have a more general-purpose solution. Could the livequery approach (of watching for DOM manipulation) be done in a stack-agnostic fashion rather than by hooking JQuery routines? If we could do that then we’d have a UJS package we could use no matter which JavaScript base library we choose — or perhaps whichever library chooses us.

• it separates behavior (JavaScript) from markup (HTML) and this is good for the same reasons separating style (CSS) from markup is good
• it can reduce page weight

I had been using ujs4rails but that thing is being deprecated so it isn’t an option for me. If I want to do UJS I can either use Prototype or JQuery. I don’t know of any other good options.

I’m using JQuery a bit now. Pretty light use: a highlight effect here, a show/hide toggle there; some AJAX form submission. In thinking about how to proceed I’m kind of torn. I don’t want to use both JQuery and Prototype longer term. For starters, that’s too much mental baggage to carry around — one must gain fluency in one or ‘tother I think. Also it’s a lot of page weight to load both libraries.

Another dimension is RJS vs. POJS. RJS is Rails’ templating and API that lets you generate JavaScript from Ruby. POJS is “Plain Old JavaScript”. If we do RJS then we almost have to stay on the Prototype stack. But with POJS a guy could go with either stack and in fact I think the scale tips to the JQuery stack for POJS as I’ll show in a sec.

So here’s how I see the top two options:

RJS: Prototype + Scriptaculous + RJS + Dan Webb’s Lowpro:
+ Lowpro supports UJS
+ most of us have used prototype + scriptaculous and are somewhat comfortable with it
+ native Rails (RJS) support
- Lowpro is not as well documented (nor as widely used) as JQuery for UJS
- I see no centralized library of plugins (other than Scriptaculous itself) for this stack

POJS: JQuery + MinusMOR:
+ it supports UJS out of the box in a pretty clean way
+ people I respect seem to be moving to JQuery
+ there is a large library of plugins including autocompleters and flash upload progress indicators
- very little native Rails (RJS) support — you can do some things but it’s hard to know exactly what will work
- if you already know scriptaculous effects, you have to learn new effects

A big part of this decision hinges on the value of RJS. After using Rails RJS templates for a year and a half or so my conclusion is that they are more trouble than they are worth. Many believe RJS is easier to write/maintain that POJS — especially for a Ruby programmer. I believe RJS is actually a false economy. In real applications you really have to code in real JavaScript.

An RJS template generates JavaScript from Ruby code — but that Ruby API is insufficiently documented (in particular with regard to the scriptaculous effects) and insufficiently capable (e.g. there is no easy way to update DOM elements matching a CSS selector through that API). Essentially a guy can waste a lot of time trying to get RJS to work for anything but the simplest demos. So I lean toward plain-old JavaScript (POJS) instead.

I wonder what you think. Do you place higher value on RJS for real applications? Have you found an alternate stack, or perhaps a different combination of stack elements? Must I pick one stack or the other, or is it possible and profitable to use both at once?

    1 page.insert_html :bottom, page.literal( "$$( '#contact_#{@contact.id} .email-category ul').first" ), :partial => 'show', :locals => { :show => @email_address}

In Fight id Proliferation I highlighted the prevalent misunderstanding of the prototype API’s insert_html, replace_html and friends that is evident both in the Prototype documentation and in Rails. Due to that misunderstanding, many of us are polluting our HTML with many more id attributes than would otherwise be necessary. In the original post I proposed a fix to Rails to remedy the situation and allow us to use CSS selectors to identify a target HTML element for the various calls. In this post I provide a workaround you can use now, while waiting for a cleaner fix.

Previously, I pointed out that we’d really like to use page.select and more generally, any expression that produces an element, as e.g. the second parameter to page.insert_html.  So it would be really nice if this worked:

    1 page.insert_html :bottom, page.select( "#contact_#{@contact.id} .email-category ul").first, :partial => 'show', :locals => { :show => @email_address}

If that worked, we wouldn’t need an id on each element representing the email address for a contact.  Instead we’d just put an id on the contact (at the outer level) and we’d tag the parts of the contact (email address, phone number, etc) with appropriate classes. Much more microformatty.

Well, as you know, you can’t do that just now in Rails. But there is a workaround.  It’s a bit ugly but it works. And the ugliness is in the RJS, not in the HTML. So your markup is smaller and cleaner, even if you’re generating an extra line of JavaScript.

The workaround is to use the each method on the result of calling page.select. This lets you iterate (in the browser) over the elements returned from evaluating the CSS selector. Within that iteration, you have available the element of interest. Now that you’ve got an element, you can call the various page methods that require an element or id such as page.insert position, element. You can also call methods directly on the element itself such as element.reset. Here’s the previous example recast in this way:

    1               page.select( "#contact_#{@contact.id} .email-category ul").each do |element|
    2                 page.insert_html :bottom, element, :partial => 'show', :locals => { :show => @email_address}
    3               end

This works great in Rails 1.2 even if it is a little bit ugly. By ugly I mean that the code doesn’t exactly express what we want. Notice that the original code was selecting the first element matched by the CSS selector whereas the workaround code is iterating over all elements matched. So long as you’re careful to construct CSS selectors that match exactly the number of elements you’re really after though, you should be ok.

Here’s a similar snippet but this one calls the Prototype reset method on the element:

    1               page.select( "#contact_#{@contact.id} .email-category form").each do |element|
    2                 element.reset
    3               end

By tagging only top-level elements with id’s and using classes to tag internal components you end up with cleaner HTML. This is valuable anywhere you present a list of complex, editable objects. For example, here is one contact of many displayed in a list:

Each contact has a set of email addresses, blog URL’s and phone numbers. We don’t want to have to assign id’s to every single phone number, blog URL and email address on the page. Instead we assign id’s only to the top-level elements. Here is a contact list with contact_19 expanded. Under contact-details we’ve got email addresses under an element with classes contact-category and email-category. That element contains both the unordered list of email addresses and a form to add new ones:

    1 <ul class="contacts-list editable">
    2     <li id="contact_25" class="contact-summary">
    3     </li>
    4     <li id="contact_19" class="contact-summary">
    5         <div class="name">support@thought-propulsion.com</div>
    6         <div class="contact-details" style="">
    7             <div class="contact-category email-category">
    8                 <h2>Email Addresses</h2>
    9                 <ul>
   10                     <li>support@thought-propulsion.com</li>
   11                 </ul>
   12             </div>
   13             <div class="contact-category blog-category">
   14             </div>
   15             <div class="contact-category phone-category">
   16             </div>
   17         </div>
   18     </li>
   19     <li id="contact_22" class="contact-summary">
   20     </li>
   21 </ul>

So if you want to use Simply Helpful to generate your top-level id’s have at it, but you needn’t use it to generate id’s for all the internal parts just because of a little misunderstanding :)

Bruce’s solution is comprised of a Ruby function showing_progress which he suggests you use in every single call to (insert_html, replace_html, replace) to wrap any options you’d normally pass to those routines. The showing_progress routine adds :loading and :complete handlers that will show, then hide an element with id ‘progress’ on your page.

The solution is kind of elegant and it works as advertised but I ran into a few problems as I got deeper into my app:

1. I forgot to call showing_progress in new invocations of insert_html, replace_html, replace — as a result I didn’t get progress indication in those cases
2. The solution works only for Ruby RJS code — if you write JavaScript that calls Ajax.Request and Ajax.Updater then the solution of course doesn’t help.
3. The solution ruthlessly overwrites any :loading and :complete handlers you’ve defined in your options

How about a solution that works for both Ruby and JavaScript? It’d be nice if it didn’t rely on the programmer remembering to call it everywhere? It’d be even nicer if it didn’t interfere with your application’s :loading and :complete handlers.

Here’s the solution I’m using. I don’t recall where I first saw it but I’m pretty sure I didn’t invent it. I see Nicky Peeters was suggesting a similar thing over a year ago. Just put this code in application.js:

    1 Ajax.Responders.register({
    2 onCreate: function() {
    3  if($('progress') && Ajax.activeRequestCount>0)
    4  Effect.Appear('progress',{duration:0.5,queue:'end'});
    5 },
    6
    7 onComplete: function() {
    8  if($('progress') && Ajax.activeRequestCount==0)
    9  Effect.Fade('progress',{duration:0.5,queue:'end'});
   10 }
   11 });

And stick something like this in your layout:

    1                 <span id='progress' style='display:none;'>
    2                     <img src='/images/busy.gif'>
    3                 </span>

And you’ll have one less worry in your life.

As explanations go, it doesn’t get much more straightforward than Cody Fauser’s excellent post on Rails RJS Templates. When you try it out though, you may notice that TextMate doesn’t know that RJS templates which by convention have an “.rjs” suffix, are really Ruby code. If you want to make TextMate aware of the “.rjs” suffix simply open the Bundle Editor window, navigate to the Ruby bundle, scroll down to the Ruby language definition (it has a Gray circular icon with an “L” on it), and add ‘rjs’ to the list of fileTypes.

Once you do that, TextMate will treat .rjs files like other Ruby files and you’ll get syntax highlighting and stuff.