Ajax|rails
A brief history of Ajax
In just a few months, Ajax has become the hottest thing from a very obscure and rare technique. This article will introduce the extremely Easy-to-use AJAX support-implemented as part of the Ruby on Rails Web application framework.
This article is not a detailed tutorial, so I assume you've learned a little bit about how to organize and build a rails Web application.
The first appearance was the World Wide Web. Compared to desktop applications, Web applications are pretty slow and boring. In any case, people like web apps because they can surf the internet wherever they are, as long as they have a browser installed on their computers. After that, Microsoft created the XMLHttpRequest in Internet Explorer 5, which allows browser-side JavaScript to communicate with the Web server in the background without requiring a browser to display a new Web page. This makes it possible to develop more fluent and responsive web applications. Mozilla soon implemented XMLHttpRequest in its browser as well as companies such as Apple (Safari browser) and opera.
XMLHttpRequest must have been one of the best kept secrets on the web. Since its debut in 1998, only a few sites have used it, and most developers, if they have ever known it, have never used it. Google has finally changed the situation-it has released a series of highly-contoured web applications that have a sleek, novel UI, supported by XMLHttpRequest technology. The most visually appealing is Google Maps, which gives you the illusion of being able to drag a mouse around an infinite size map in its tiny window.
When the fact that Google highlighted the use of XMLHttpRequest dramatically improved the UI effect of the Web application, it was Jesse James Garrett's paper that eventually gave the technology a usable name: Ajax ( asynchronous JavaScript and XML). If we don't know it yet, our entire industry may still be waiting. The new Ajax names are now spreading like wildfire. I've never seen so fast and so close to adopting a new technology!
Comparison of traditional Web applications with AJAX applications
Let's analyze a usage case-insert a new item into a list-and take a look at the essence of an AJAX Web application.
A typical user interface is implemented in the example-the current list is displayed in a Web page followed by an input field-the user can enter the text of a new item here. When the user clicks on a new Item button, the application actually creates a key and inserts a new item into the list.
In this case, a traditional Web application sends input field values to the server, and then the server acts on the data (usually by updating a database) and by sending back a new Web page-it displays an updated list containing the new item-as a response. This situation takes up a lot of bandwidth because most new page content is exactly the same as it was originally. The performance of this Web application gradually declines as the list grows.
Instead, an AJAX Web application sends input fields to the server in the background and changes only the part of the current Web page that is affected. This greatly improves the responsiveness of the user interface, making it feel like a desktop application.
You can test these effects yourself. Here are some links to different blogs, one of which uses Ajax to send evaluations and the other is useless. You can send them to each other for experiments:
• Traditional Web applications
· Ajax Web Applications
Note that Ajax is only about usability. But, like any technology, you can use it efficiently, and it can be used inefficiently. After showing how to use Ajax, I'll give you some simple tips on when to use Ajax.
Iii. How to use Ajax in Web applications
The more troublesome way to use AJAX technology in your Web application is to create your own custom javascript-that uses the API of the XMLHttpRequest object directly. To do this, you have to deal with the characteristics of each browser.
An easier way to do this is to use a JavaScript library-it provides a higher level of AJAX service and hides the differences between browsers. Libraries like Dwr,prototype,sajax and ajax.net are good choices.
The easiest way to do this is to use the built-in Ajax tools in rails. In fact, rails makes Ajax so easy that in typical situations, using AJAX and not becoming almost as easy.
Iv. How rails implements Ajax
Rails has a simple consistency model to implement AJAX operations.
Once the browser generates and displays the starting Web page, different user actions require it to display a new Web page (like any traditional Web application) or to trigger an AJAX operation:
1. A trigger action occurs. This could be a user clicking on a button or a hyperlink or a user changing the data in a form or a field, or just a cycle of triggers (based on a timer).
2. Data associated with triggers (a field or a complete form) is sent asynchronously via XMLHttpRequest to an action processor on the server.
3. The server-side action processor takes some action based on this data (which is why it is called an action processor) and returns an HTML fragment as its response.
4. Client JavaScript (created automatically by rails) receives the HTML fragment and uses it to update the specified portion of the current HTML page, often the content of a
label.
An AJAX request to the server may also return any data, but I'll just discuss the HTML fragment. The real beauty lies in how easily rails makes it easy to implement these in your Web application.
[1] [2] [3] [4] Next page
