摘要
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。