二、 传统型Web应用程序与Ajax应用程序的对比

　　让我们通过分析一个使用案例-把一个新项插入到一个列表中-来看一下一个Ajax web应用程序最本质的所在。

　　在例中实现了一典型用户接口-在一个web页面中显示当前列表，后面跟着一个输入字段-用户在此可以输入一个新项的文本。当用户点击一个新建项目按钮时,应用程序实际上创键并把一个新项插入到列表中。
　
　　在这种情况下,一传统型web应用程序会发送输入字段值到服务器；然后，服务器作用于数据(通常通过更新一数据库)并通过发送回一个新的web页面-它显示一个被更新后的包含该新项的列表-作为响应。这种情况占用了很多带宽,因为大多数新的页面内容与原先的完全一样。这个web应用程序的性能随着列表的增长而逐渐下降。

　　相反，一个Ajax web应用程序在后台发送输入字段到服务器并且只更改当前web页面受到影响的部分。这大大提高了用户接口的响应能力，使它感觉起来象一个桌面应用程序。

　　你可以亲自试验一下这些效果。下面是一些到不同博客的链接，其中的一个使用Ajax来发送评价而另一个没用。你可以在它们之间相互寄送进行实验：

　　·传统型的Web应用程序

　　·Ajax Web应用程序

　　注意，Ajax仅仅在于使用性。但是，就象任何技术一样，你可以高效地使用它，也可能低效地使用。在展示了怎样使用Ajax之后,我将给出一些关于何时使用Ajax的简单建议。

三、 怎样在Web应用程序中使用Ajax

　　在你的web应用程序中使用Ajax技术的较麻烦的方法是创建你自己的定制JavaScript-它直接使用XMLHttpRequest对象的API。为此，你必须处理每种浏览器的特性。

　　一个较容易些的办法是使用一个JavaScript库-它提供了较高级的Ajax服务并且隐藏了浏览器之间的差别。象DWR,Prototype,Sajax和Ajax.NET这样的库都是很好的选择。

　　最容易的办法是使用Rails中内建的Ajax工具。事实上,Rails使Ajax变得如此容易，以至于在典型情况下，使用Ajax和不用变得几乎一样容易。
四、 Rails是怎样实现Ajax的

　　Rails拥有一个简单的一致性模型来实现Ajax操作。

　　一旦浏览器生成并显示了起始web页面，不同的用户操作要求它显示一个新的web页面(就象任何传统型的web应用程序)或触发一个Ajax操作:

　　1. 发生一个触发器行动。这可能是用户点击一个按钮或一个超级链接或者用户改变了表单中的数据或字段中的数据，或只是一个周期的触发器(基于一个定时器)。

　　2. 与触发器相联系的数据(一个字段或一个完整的表单)经由XMLHttpRequest被异步地发送到服务器上的一个行动处理器。

　　3. 服务器端行动处理器基于这些数据采取一些行动(这就是为什么称为一个行动处理器),并且返回一个HTML片断作为它的响应。

　　4. 客户端JavaScript(由Rails自动地创建)收到该HTML片断并且使用它更新当前HTML页面指定的部分，经常是一个＜div＞标签的内容。

　　一个到服务器的Ajax请求也可能返回任意的数据,但是我将仅讨论一下HTML片断。真实的美丽在于Rails使得在你的web应用程序中实现这些是多么地容易。

五、 使用link_to_remote

　　Rails有若干帮助者方法以在你的视图的模板中实现Ajax。一种最简单且很通用的方法就是link_to_remote()。让我们考察一个简单的web页面-它实现询问时间并且有一个链接，用户可以点击这个链接来获得当前的时间。该应用程序经由link_to_remote()使用Ajax以检索时间并且显示它于web页面。

　　我的视图模板(index.rhtml)看起来象: 

＜html＞
＜head＞
＜title＞Ajax Demo＜/title＞
＜%= javascript_include_tag prototype %＞
＜/head＞
＜body＞
＜h1＞What time is it?＜/h1＞
＜div id=time_div＞
I don’t have the time, but
＜%= link_to_remote( 点击这里,
:update =＞ time_div,
:url =＞{ :action =＞ :say_when }) %＞
and I will look it up.
＜/div＞
＜/body＞
＜/html＞

　　上面的模板中有两个很有意思的帮助者方法，以粗体标出。javascript_include_tag()包括了Prototype JavaScript库。所有的Rails Ajax特性都使用这个JavaScript库-它被包含在Rails分发包之中。

　　这里的link_to_remote()调用使用了它的最简单的形式,有3个参数：

　　1. 要显示的链接文本-在本例中是,点击这里。

　　2. DOM元素的id，它包含将用行动执行结果进行替换的内容，在本例中是time_div。

　　3. 要调用的服务器端行动的URL-在本例中是,一个叫作say_when的行动。



图1.点击链接前

　　我的控制器类看起来象:

class DemoController ＜ ApplicationController
def index
end
def say_when
render_text ＜p＞The time is ＜b＞ + DateTime.now.to_s + ＜/b＞＜/p＞
end
end

图2.点击链接后

　　这里的索引行动处理器不做任何东西，除了让Rails承认有一个索引行动并生成index.rhtml模板外。这个say_when行动处理器构建一个HTML片断-它包含当前日期和时间。图1和2显示了在点击点击这里链接前后索引页面是怎样显示的。

　　当用户点击点击这里链接时,浏览器构建一个XMLHttpRequest对象,并把它发送到服务器-伴随一个将调用say_when行动处理器的URL-它返回一个包含当前时间的HTML响应片断。客户端JavaScript接收到该响应并且通过它来用一个time_div id替换＜div＞的内容。

　　也有可能插入这个响应,而不是代替现有内容:

＜%= link_to_remote( 点击这里,
:update =＞ time_div,
:url =＞ { :action =＞ :say_when },
:position =＞ after ) %＞

　　我增加了一可选的参数:position=＞after-它让Rails嵌入返回的HTML片断于目标元素(time_div)之后。位置参数能接受值before,after,top,和bottom-其中top和bottom插入到目标元素的内部,而before和after插入到目标元素的外部。

　　在任何情况下,既然我添加了位置参数,那么点击这里链接就不会消失。因此，我可以不断地点击它并观察新加到页面上的时间。



图3.在位置选项插入新的内容

　　这个web页面和被浏览器显示的URL都没有改变。在这样类似的小例子中，即使对一个完整的页面更新也节省不了多少时间。但是，当你有一更复杂的页面而其中仅需要更新很小的一部分时，这种差别将变得非常显著。

六、 使用form_remote_tag

　　这个form_remote_tag()帮助函数与link_to_remote()很相似，除了它也发送一个HTML表单的内容之外。这意味着该行动处理器可以使用用户输入的数据来形成响应。这个实例显示了一个web页面-它有一个列表和一个支持Ajax的表单-该表单能够让用户添加一些选项到该列表中。

　　我的视图模板(index.rhtml)看上去象: 

＜html＞
＜head＞
＜title＞Ajax List Demo＜/title＞
＜%= javascript_include_tag prototype %＞
＜/head＞
＜body＞
＜h3＞Add to list using Ajax＜/h3＞
＜%= form_remote_tag(:update =＞ my_list,
:url =＞ { :action =＞ :add_item },
:position =＞ top ) %＞
New item text:
＜%= text_field_tag :newitem %＞
＜%= submit_tag Add item with Ajax %＞
＜%= end_form_tag %＞
＜ul id=my_list＞
＜li＞Original item... please add more!＜/li＞
＜/ul＞
＜/body＞
＜/html＞

　　请注意上面加粗的两部分，它们定义了表单的开始和结束。因为该表单以form_remote_tag()而不是form_tag()开始,应用程序将使用XMLHttpRequest提交这个表单。form_remote_tag()中的参数看上去是:

　　·更新参数用于指定DOM元素的id及行动执行结果要更新的内容-在本例中是my_list。

　　·url参数用于指定服务器端行动-在本例中，调用一个称为add_item的行动。

　　·位置参数代表插入到my_list元素顶部的返回的HTML片断-在本例中是一个＜UL＞标签



图4.在增加任何项前

　　我的控制器类看起来象下面这样:

class ListdemoController ＜ ApplicationController
def index
end
def add_item
render_text ＜li＞ + params[:newitem] + ＜/li＞
end
end 

　　add_item行动处理器构建一个HTML列表项片断，它包含输入到表单的newitem字段中的任何文本。



图5.添加几个新的列表项之后

＜label for=searchtext＞Live Search:＜/label＞
＜%= text_field_tag :searchtext %＞
＜%= observe_field(:searchtext,
:frequency =＞ 0.25,
:update =＞ :search_hits,
:url =＞ { :action =＞ :live_search }) %＞
＜p＞Search Results:＜/p＞
＜div id=search_hits＞＜/div＞ 

　　这个代码小片段实现监视一个称为searchtext的文本框字段的值。每隔四分之一秒，Rails检查该字段的变化。如果该字段发生变化，浏览器将作一个到live_search行动处理器的Ajax调用,并把结果显示在search_hits div中。

　　你可以在我的博客上看到一个这种现场查找的实际展示。在右上角的搜索框中，你可以试着输入enterprise或rails，看看发生了什么。

　　八、 是否应用Ajax技术

　　当你使用Ajax技术来更新一个web页面部分时,用户得到的是快速响应性和流畅性。然而,用户也失去了书签功能和使用浏览器的向后按钮的能力。这两个缺点来源于同一个事实：URL不做改变，因为浏览器并没有装载一新的页面。

　　不要仅因为Ajax相当酷而使用它，而应考虑在你的web应用程序的用户接口中什么最为重要。

　　例如,如果一个web页面显示一个帐户列表-上面有一些诸如添加、删除和改名帐户等等的操作，这些都是Ajax的良好候选。如果用户点击一个超级链接来显示属于一个帐户的所有清单-这种情况下，你应该显示一新页面并且避免Ajax。

　　这意味着用户能够记下该帐户页面和清单页面,并且使用向后和向前按钮在它们之间切换。用户不能够记下所有这些列表之一中的操作或使用向后按钮来尝试撤消一个在该列表上的操作(在一传统型web应用程序中，这两者你也都希望避免发生)。

　　九、 添头

　　我想介绍给你许多真正酷的东西，但是却不会深入到细节中去讨论。

　　Web页面上载文件的功能经常令一些用户紧皱眉头，因为用户在上载处理过程中，他不会收到任何反馈信息，除了屏幕上漏斗鼠标在不停地转转转……通过使用Ajax技术,你可以与服务器进行通讯-在上传过程中，可以检索和显示上传的状态。Sean Treadway和Thomas Fuchs实现了一个有关如何实现这种技术的现场展示，这是通过使用Rails和一个视频来实现的。

　　另外，Rails使用的Prototype JavaScript库也实现了大量的可视化效果。效果演示页面上有一个这些效果的在线演示，其中包括JavaScript对使用之的调用。

　　十、 感想

　　自从孤立的web站点服务于静态的页面以来，Web已经经历了一段相当长的里程。如今，我们在慢慢地进入到一个新的时代-站点动态地相互链接在一起,web API允许我们容易地在已有的服务上进行这样的创建,而且web用户接口已变得越来越流畅和具有快速响应性。很明显，Ajax在如今已浮出水面的Web 2.0传奇中将占有举足轻重的地位。

　　无论如何，把复杂的Ajax特征增加到一个web应用程序应该是一堆相当大量的工作,但是Rails使得所有这些变得太简单了。