开发保留标准的浏览器功能的AJAX应用

【 tulaoshi.com - Web开发 】

摘要

AJAX应用因为它们的表现力的丰富、更加互动和更加迅速的响应得到了赞扬声；这些优点都是通过使用XMLHttpRequest对象来动态的载入数据而获得的，而不是重新载入新的页面。在大量的宣传和刺激中，却有一些批评的声音指出，AJAX应用破坏了一些重要的浏览器特性，这其中包括对前进/后退按钮的支持。

本文首先解释了为什么除非明确的将那些功能做进AJAX应用，否则前进/后退按钮和其他一些浏览器功能不能正常工作。然后简单的列出开发者如何解决上述问题，最后我们将详细的看一看Backbase AJAX引擎是如何提供对前进/后退按钮和其他一些浏览器功能的支持的。

AJAX应用需要一个后退按钮吗？

AJAX许诺允许开发者仅仅使用标准的浏览器技术开发有更好用户体验的和高度互交的WEB应用，这种技术常常是指DHTML。

以前，开发者常常不得不在rich和reach之间做出选择；前者是指具有高度互交性的交互式的用户接口，后者是指一个运行在所有WEB浏览器上的、不用额外的安装机制的前台终端。AJAX应用将使得前台终端既“rich”又“reach”。

但是到底什么是真正的一个界面“rich”的含义呢？而什么又是一个应用“reach”的含义呢？

“rich”的概念不容易定义，但是容易被直观的感受。如果你看到一个“rich”界面，你将明白什么是“rich”界面。桌面应用像微软的Office就是一个“rich”的界面。一个“rich”的界面使用先进的UI控制技术，如Tabs和上下文菜单。它们提供前进的互交手段，像当它们获得焦点的时候，UI元素的drag-and-drop和highlighting。传统的浏览器应用不是“rich”的。它们被限制在一些简单的控制器里，像Form，而交互只是简单的依靠点击链接到一个新的页面。看看微软的email客户端就能看出其中的差别：Outlook是“rich”的，而hotmail则不是。

AJAX应用因为它们的富有的表现力而得到表扬，Google的Gmail就是一个经常提及的例子。其他的Google所做的AJAX应用，如Google Suggest和Google Map。微软即将发布的Web mail客户端，代号为：“Kahuna”，或者Backbase RSS Reader也包含了高级的控制器和互交的模型。看一看Dan Grossman的列表：Top 10 Ajax Applications，那里是一些激动人心的关于“rich”界面的列表。
因此我可以得出结论，AJAX应用很明白的满足“rich”的概念。但是它是否满足“reach”呢？

在AJAX应用的绝大多数基本表单里，如果界面运行在一个WEB浏览器里，那么这个应用是“reach”的。AJAX应用是基于标准的浏览器的，因此能够被一个浏览器所访问。

但是，仅仅被浏览器所理解还是不够的。Jakob Nielson在他的文章Flash: 99% Bad里，指出Flash：“破坏了WEB的基本的交互风格”。在使用WEB应用的时候，终端用户期望一个确定的交互风格。应用需要提供传统的WEB交互风格，并且提供如下的可用性特性：

。必须提供“后退/前进”按钮，用户能够浏览网页历史纪录

。用户能够使用书签

。必须提供Deep links，以便用户能够将其通过email发送给朋友或同事

。必须提供“刷新”按钮，用来刷新当前状态，而不是通过重新初始化应用来获得

。开发人员可以通过使用“view source”来查看源代码

。终端用户能够使用“find”来搜索页面

。搜索引擎能够对网页编索引，能够产生一个Deep link来搜索它们

看一看10个顶级的AJAX应用，表明大多数的当前AJAX应用的确破坏了WEB的基本交互风格。在接下来的部分里，我们将看一看为什么很多的AJAX应用会这样。

为什么AJAX应用经常性的破坏了后退按钮？

我们今天所知道的WEB牢固的建立在以下三个原则的基础上：

。使用（D）HTML建立的界面

。使用HTTP为客户/服务器通讯

。使用URIs寻址

上面的原则决定了我们所获取的WEB应用有一定的局限性，而AJAX应用正是通过冲破这种局限性的限制而使得界面变得更加丰富。正像我以前的文章：A Backbase Ajax Front-end for J2EE Applications所解释的。AJAX引入了广泛使用的java script（AJAX中的J）来创建丰富的UI界面控制器和交互。AJAX也引入了异步的XML通讯（AJAX中的A和X），这是通过引入XMLHttpRequest对象来载入新的数据和表现层逻辑，而没有页面刷新。然而，当前的AJAX模型，不能够定位如何处理URIs。

作为改变使用（D）HTML和HTTP的一个直接后果，AJAX应用破坏了作为WEB基本交互风格的后退按钮和其他的元素。在本文余下的部分，我将解释如何在AJAX方式下通过处理URIs来修补这种破坏。我首先将说一说为什么URIs会和传统的WEB应用的交互有关系。
用户交互用术语来说就是用户界面的状态发生了改变。终端用户发起了状态改变，浏览器客户端通过发送页面请求到服务器的方式来处理状态变化（REST原则），服务器通过发送一个新的页面和新的URIs到客户端来产生一个新的界面状态。

简而言之，每一个用户交互是这样别处理的，通过服务器的循环产生如下的结果：

。产生一个新的页面

。产生一个新的URI

因为浏览器记录了连续的URIs到它的历史堆栈里，并且将当前的URI显示在地址栏里，WEB的可用性特性就被激活。在地址栏里，用户可以拷贝URI，并且可以把它发送给朋友。当用户点击返回按钮或从email里粘贴一个URI到地址栏里，一个到服务器的循环就被触发。由于服务器负责状态管理，那么服务器就能产生相应的页面。

AJAX应用和传统的WEB应用的最大的不同在于AJAX应用能够不通过页面的重载而处理用户的交互。通过XMLHttpRequest对象从服务器载入数据就是一个例子。使用java script处理客户端drag-and-drop是另外的一个例子。

在上面的两个例子中，状态的变化不是通过产生一个新的URI得到的。因此，点击后退按钮或者刷新按钮不能得到想要的效果，并且在地址栏里没有deep-link的URI。

为了提供传统的WEB可用性特性，AJAX应用需要像传统的WEB应用一样来处理URIs客户端。因此AJAX应用需要做如下的事：

。当一个客户端状态变化时，产生一个URI，并且发送到客户端

。当一个新的URI被客户端请求时，保存状态

做到了上面的两点，浏览器的历史纪录将会工作，浏览器的地址栏将显示一个能发送给朋友的URI。

另外一个困难是决定什么时候AJAX引擎应该做上面的那两件事（例如，什么样的状态变化将导致产生一个新的URI）。在传统的模式中，每一个页面刷新都导致一个URI的更新。在AJAX模式中，每一个客户端事件都可能产生一个URI到浏览器堆栈。交互设计师和开发者将决定什么样的状态变化是有意义的。因而只对那些有意义的状态变化产生新的URI。