Ajax on RailsIn a few short months, Ajax has moved from an obscure and rarely used technology to the hottest thing since sliced bread. This article introduces the incredibly easy-to-use Ajax support that is part of the Ruby on Rails web application framework. This is not a step-by-step tutorial, and I assume that you know a little bit about how to organize and construct a Rails web application. If you need a quick refresher, check out Rolling with Ruby on Rails, Part 1 and Part 2.
Just in case you've been stranded on a faraway island for most of the year, here's the history of Ajax in 60 seconds or less.
XMLHttpRequest must have been one of the Web's best kept secrets. Since its debut in 1998, few sites have used it at all, and most developers, if they even knew about it, never used it. Google started to change that when it released a series of high-profile web applications with sleek new UIs powered by XMLHttpRequest. The most visually impressive of these is Google Maps, which gives you the illusion of being able to drag around an infinitely sizable map in its little map window.
Traditional Web App vs. an Ajax App
Let me distill the essence of an Ajax web application by examining a use case: inserting a new item into a list.
A typical user interface displays the current list on a web page followed by an input field in which the user can type the text of a new item. When the user clicks on a Create New Item button, the app actually creates and inserts the new item into the list.
At this point, a traditional web application sends the value of the input field to the server. The server then acts upon the data (usually by updating a database) and responds by sending back a new web page that displays an updated list that now contains the new item. This uses a lot of bandwidth, because most of the new page is exactly the same as the old one. The performance of this web app degrades as the list gets longer.
In contrast, an Ajax web application sends the input field to the server in the background and updates the affected portion of the current web page in place. This dramatically increases the responsiveness of the user interface and makes it feel much more like a desktop application.
You can see this for yourself. Below are links to two different weblogs, one that uses Ajax to post comments and another that does not. Try posting some comments to each one:
Traditional Web App
Ajax Web App
Ajax is all about usability--but like any technology or technique, you can use it well or use it poorly. After showing how to use Ajax, I'll give some guidelines on when to use Ajax and when not to.
How to Use Ajax in Your Web Application
The easiest way of all is to use the built-in Ajax facilities of Ruby on Rails. In fact, Rails makes Ajax so easy that for typical cases it's no harder to use Ajax than it is not to!
How Rails Implements Ajax
Rails has a simple, consistent model for how it implements Ajax operations.
Once the browser has rendered and displayed the initial web page, different user actions cause it to display a new web page (like any traditional web app) or trigger an Ajax operation:
1. A trigger action occurs. This could be the user clicking on a button or link, the user making changes to the data on a form or in a field, or just a periodic trigger (based on a timer).
2. Data associated with the trigger (a field or an entire form) is sent asynchronously to an action handler on the server via XMLHttpRequest.
3. The server-side action handler takes some action (that's why it is an action handler) based on the data, and returns an HTML fragment as its response.
An Ajax request to the server can also return any arbitrary data, but I'll talk only about HTML fragments. The real beauty is how easy Rails makes it to implement all of this in your web application.
Rails has several helper methods for implementing Ajax in your view's templates. One of the simplest yet very versatile methods is link_to_remote(). Consider a simple web page that asks for the time and has a link on which the user clicks to obtain the current time. The app uses Ajax via link_to_remote() to retrieve the time and display it on the web page.
My view template (index.rhtml) looks like:
The link_to_remote() call here uses its simplest form, with three parameters:
1. The text to display for the link--in this case, "click here".
2. The id of the DOM element containing content to replace with the results of executing the action--in this case, time_div.
3. The URL of the server-side action to call--in this case, an action called say_when.
Figure 1. Before clicking on the link
My controller class looks like:
Figure 2. After clicking on the link
The index action handler doesn't do anything except letting Rails recognize that there is an index action and causing the rendering of the index.rhtml template. The say_when action handler constructs an HTML fragment that contains the current date and time. Figures 1 and 2 show how the index page appears both before and after clicking on the "click here" link.
It's also possible to insert the response, instead of replacing the existing content:
I added an optional parameter :position => "after", which tells Rails to insert the returned HTML fragment after the target element (time_div). The position parameter can accept the values before, after, top, and bottom. top and bottom insert inside of the target element, while before and after insert outside of the target element.
In any case, now that I added the position parameter, my "click here" link won't disappear, so I can click on it repeatedly and watch the addition of new time reports.
Figure 3. The position option inserts new content
The web page doesn't change, and neither does the URL being displayed by the browser. In a trivial example like this, there has not been much of a savings over an entire page refresh. The difference becomes more noticeable when you have a more complicated page of which you need to update only a small portion.
Автор: Curt Hibbs