Wednesday, March 16th, 2005

Ajax in Ruby on Rails

Category: Ajax, Ruby

David Heinemeier Hansson and Jamis Buck, are putting Ajax-aware components into Rails.

Jamis is talking about whether to sync, or not to sync….

One of the great benefits to XMLHttpRequest is the fact that you can do work asynchronously. If you can possibly make your UI so it doesn’t ‘hang’, you should do so. However, if you really NEED to block on something for a good reason, then it makes sense to go that route. I normally try to work my UI to handle the asychronous use case as much as possible.

Although the following is easy:

element.innerHTML = submit_request(“/some/action?value=foo”)

If possible, I would really want to make sure that we don’t equate “this is easy” with “this is what we should do”.

Rails simple approach

It looks like Rails is going to have a very simple approach to adding Ajaxian components. The approach marries the world of partials in Rails, and returning arbitary HTML from the server-side, and having the client code innerHTML the responseText.

This covers the 80/20 rule, and gives Rails developers a very simple interface. It also has the benefit of bypassing the pain of the DOM.

There is more though…

While I like having this tactic as PART of the solution, I do also want to see a common set of XML parcels for other common tasks:

  • dom-remove: Given an id, nuke it from the DOM
  • dom-replace: Given an id, and new content, do a replace
  • dom-insert: …

as well as the generic solutions such as:

  • Put this HTML at this point
  • Run this piece of JavaScript (so the server side can control anything)

The abstractions will be interesting to see. I think there are a variety of levels. One level is something like the Dojo bind(). This is a very low level abstraction about XHR/iframes/… Next we get the web frameworks which will autogen JavaScript for us. E.g. “validate on the server side via XHR” CHECK.

Posted by Dion Almaer at 12:36 am

4 rating from 9 votes


Comments feed

The common tasks you mention (remove, replace, insert) are all possible through the Ajax support that Rails will ship with. In fact, Honey, the project from which I’m extracting this support, has all of these elements in it. The trick is just to have containers stand ready for these parts.

remove: fill the container with no text
replace: that’s the default case
insert: fill an empty container with content

Additionally, all of the Ajax helpers have the possibility of defining callbacks. So you can say, call this remote method and trigger this JS.

We’re also coming out with form and field observers that can watch for changes and trigger methods when they occur. Great for Google Suggest and Textarea Previews.

So, in all humility, I believe this is more of a 95/5 abstraction ;)

Comment by David Heinemeier Hansson — March 16, 2005

(Linebreaks not rendered in preview? Let’s hope they make it!)

For the generic “Put this HTML at this point”, I wrote similar stuff when I wired up the Batik SVG DOM to the Jabber/XMPP IM protocol.

Like you, my solution was to provide analogs to the four main DOM operations (including append), however the point(s) in the document at which the modifications are made is specified by an XPath expression.

For example you can use simple XPath expressions to say something like:

“insert Chapter 3 before element(s) matching /book/chapter[3]”


“append to all elements matching /book/chapter”

(The actual grammar is in XML, with a complete explanation at ( for anyone who’s interested.)

When it comes to doing this on a less obscure platform, the problem is that XPath is only supported on Seamonkey and IE, via two different APIs (of course).

The Sarissa project ( acts as a compatibility layer for these two, but unfortunately Opera and Safari don’t support XPath at all.

Comment by Ian Sollars — March 16, 2005

Is there any discussion forum to ask Ajax related questions?

Comment by Brent Jase — March 16, 2005

Leave a comment

You must be logged in to post a comment.