简介

世界上最权威的关于ajax的系统介绍

译者：本文是世界上第一篇关于ajax系统性介绍。作者通过这篇文章创造了"ajax"(阿迦克斯)这个词。

目前这种隔阂正在被打破。看看google建议(Google Suggest)。当你敲上一个新词时，建议的词汇几乎是立即出现的。再看看Google Maps，使用你的鼠标抓取地图并稍稍移动，再移动，一切都会立即出现，而不需等待页面刷新。

Google Suggest和Google Maps是这种新实现途径的2个例子，在Adaptive Path我们称之为Ajax。这个名字是异步JavaScript+XML的缩写。它代表了一种在web之上可能实现的基本方式。

定义Ajax：

Ajax并不是一项技术。它实质上是用一种强大的新方式结合在一起的一系列技术集，其中的每一项技术都在他们自己的领域里面相当流行。Ajax包括：

·使用XHTML和CSS创造基于标准的呈现;

·使用文档对象模型(DOM)的动态响应与交互;

·使用XML和XSLT进行数据数据交互和处理;

·使用XMLHttPRequest进行异步的数据检索;

·使用javascript绑定一切;

经典的 web应用模型是这么工作的：在界面上的大多数用户操作都能触发一个http的请求传回web服务器。服务器进行一些处理－－检索数据，处理数据，与其他 的早期系统进行交互－－然后传回一个http页面返回客户端。这个模型是根据Web最初的超文本链接方式编写的。但是作为《The Elements of User Experience》的fans,我们知道，让web与超文本高效融合的实现方式与编写好的软件应用并无直接联系。

图片1：传统的web应用模型(左)与Ajax模型的对比(右)

这个实现方式很有技术上的感觉，但它无助于创造更好的用户体验。当服务器在做这些事情的时候，用户在干什么？没错，是等待。而在这项任务里面的每一 步，用户都要等待若干时间。显然，如果我们要从头设计一个符合要求的web应用，我们不能让用户这么一直呆呆地等着。页面装载完成后，为什么一旦应用程序 需要从服务器上获取数据时，都要让用户中断他们的交互？事实上，为什么要让用户看到这个(应用程序与服务器的)交互过程？

Ajax有什么不同？

一个Ajax应用程序通过在用户与服务器之间引进一种称为Ajax引擎的中间媒介，能够从根本上消除这种开始－等待－开始－等待的web交互过程。这听起来象是往程序里面添加一个抽象层(layer)而让它更少地作出响应。但事实并不如此。

在开始一个会话(session)时，浏览器加载Ajax引擎——用javascript编写并通常位于一个隐藏的frame中－－以取代加载 web页面。这个引擎同时负责为用户看到的界面进行描述以及响应用户的请求并与服务器进行交互。Ajax允许用户与服务器进行异步的交互－－独立于服务器 的通讯。因此用户就不必一直呆呆地盯着一个空白的浏览器窗口和沙漏图标，等着服务器做后面的事。

图片2:传统web应用的同步交互模式(上面)与Ajax应用的异步交互模式(下面)

用户的每个动作通常都会产生的http的请求被javascript传向Ajax引擎的调用取代了。任何关于用户动作的响应并不都需要传回服务器 ——比如简单的数据验证，在内存中修改数据，甚至包括一些导航——引擎能够自己处理这些。如果引擎需要一些要从服务器获得响应的东西——比如提交数据进行 处理，加载额外的界面代码，或检索新的数据，引擎能够让这些请求异步地发送，这通常使用XML，且无需用户停止它们与应用程序的交互。

谁在使用Ajax?

Google在完善Ajax上投入巨大。所有Google去年发布的主要产品——orkut，Gmail，最新beta版的Google Groups，Google Suggests，Google Maps——都是Ajax的应用。(想获得更多有关Ajax实现的具体细节，可以参考这些关于Google Groups，Google Suggests和Google Maps的经典分析)其他的还包括以下这些：在Flickr上许多人们喜欢的特性是通过Ajax实现的，Amazon的A9.com搜索引擎也使用了同样的技术。

这些项目表明Ajax并不只是一种技术层面的论调，同时也是现实中具有实践意义的应用。这并不是某种只存在于实验室的技术。Ajax应用可以是任何形式，从非常简单的，单函数的Google Suggest到非常复杂尖端的Google Maps。

在Adaptive Path，过去的几周里我们一直在使用Ajax，同时我们意识到我们对Ajax所能实现的丰富的交互能力以及响应只是浅尝辄止。对于web应用而 言，Ajax是一种重要的进展，同时它的重要性刚刚显示出来。已经有很多的开发人员知道如何使用这些技术，我们期望能有更多的团体在实现更有竞争力的 Ajax应用上紧跟Google的脚步。

展望未来

Ajax应用上最大的挑战并不是来自于技术。Ajax的核心技术已经是成熟，稳定，且易于理解的。相对的是，真正的挑战在于这些应用程序的设计者们：如何忘记我们所想所知的一切有关web的局限，并同时开始想象更大更宽广的可能。

这将会很有趣。

Ajax Q&A

自从我们发表了Jesse的论文后，我们收到大量读者咨询Ajax问题的信件。在以下的Q&A部分，Jesse回答了一些最常见的问题。

Q. 是Adaptive Path发明了Ajax吗？还是Google？亦或是Adaptive Path帮助google实现了这些Ajax应用？

A. Adaptive Path与Google都没有创造Ajax。Google最新的产品只不过是Ajax技术的一些儿鲜明的使用例子。Adaptive Path并不只是参与了Google关于Ajax引擎的应用。我们还为一些其他的客户开发Ajax作品。

Q. Adaptive Path在贩卖Ajax组件或注册了Ajax这个名字吗？我从哪里可以下载它？

A. Ajax并不是某种你能够下载到的东西。它实际上是一种途径——一种你用来思考如何使用特定技术建立web框架的方式。Adaptive Path并不拥有Ajax名字和技术的所有权。

Q. Ajax是XMLHttpRequest的别名吗？

A. 不是的。XMLHttpRequest仅仅只是Ajax这个技术集合中的一部分。XMLHttpRequest这个技术组件让异步的服务器通讯称为可能。 Ajax这个名字的由来在我们的文章里已经有详细的描述，它并不只依赖于XMLHttpRequest，还有CSS, DOM等等其他的技术。

Q. 为什么你觉得有必要取这么一个名字？

A. 当我与客户讨论这个实现方法的时候，我需要某个比"异步的JavaScript+CSS+DOM+XMLHttpRequest"更简短的名字。

Q. 异步服务器通讯技术已经存在很多年了。为什么说Ajax是一种"新的"实现方式？

A. Ajax是一种在现实中能够改变基本web交互模型的新的且显著的技术使用方式。Ajax之所以这么迷人是

因为这些公司明白如何最高效地使用它们从容地进行开发。

Q. Ajax是一种技术平台还是一种架构风格？

A. 两方面都是。Ajax是以某种特殊方式使用的技术合集。

Q. 最适合Ajax的是哪种应用？

A. 我们也还不清楚。这是一种互相关联的新的实现途径。我们对什么是Ajax最佳应用的理解仍处于初级阶段。有时传统的web应用模型仍是某些问题的最佳解决方案。

Q. 这意味着Adaptive Path是flash的反对者吗？

A. 没有的事。Macromedia也是我们的一个客户。而且我们长久以来一直支持flash技术。当Ajax技术成熟之后，我们希望它有时在某些问题上是一 个更好的解决方案，有时flash则会是更棒的那个。我们同样对寻找融合两种技术的途径很感兴趣。(就Flickr而言，他们就同时使用了这两种技术)

Q.Ajax有明显的可访问性或浏览器兼容性的局限吗？Ajax应用会破坏后退按钮的功能吗？Ajax能够与重置功能(REST)兼容吗？对于Ajax的发展有没有需要进行安全性的考量？对讨厌javascript的用户，有没有使用Ajax的可能？

A.所有对这些问题的回答都是"有可能"。许多的开发者已经在寻找定位这些问题的方式了。但我们认为，要确定Ajax的所有局限，仍有很多工作要做。同时我们期待Ajax的开发社区能够发现更多的这类问题。

Q.你引用的一些Google的例子完全没有使用XML。在一个Ajax应用里面，我都必须使用XML或XSLT吗？

A.XML是Ajax客户端获取及发送数据的一个相当成熟的方式。但没有任何理由限制你不能使用一些象javascript object notation之类结构化数据交互技术来实现相同的功能。

Q. Ajax应用会比传统的web应用程序更容易开发吗？

A. 这不一定。Ajax应用不可避免地需要在客户端运行复杂的javascript代码。让这些复杂的代码高效且无错误地运行并不是一件容易的事。我们同样需要一些更好的开发工具或架构来迎接这些挑战。

Q. Ajax应用程序一定会比传统的web应用程序具有更好的用户体验吗？

A. 这不一定。Ajax赋予了交互设计者们更多的灵活性。然而，我们拥有越强大的能力，在运用中我们就会有更多的细节需要关心。在我们的应用程序中我们一定要更加谨慎地使用Ajax来增强用户体验，而不是削弱它。

转自：   http://hi.baidu.com/jantouy/blog/item/c7aed9fa5cdedad9b58f312b.html