Ajax技術全解之三

Ajax適用情境

1.表單驅動的互動

傳統的表單提交，在文字框輸入內容後，點擊按鈕，幕後處理完畢後，頁面重新整理，再回頭檢查是否重新整理結果正確。使用Ajax，在點擊sunmit按鈕後，立刻進行非同步處理，並在頁面上快速顯示了更新後的結果，這裡沒有整個頁面重新整理的問題。

2.深層次的樹的導航

深層次的串聯功能表（樹）的遍曆是一項非常複雜的任務，使用JavaScript來控制顯示邏輯，使用Ajax消極式載入更深層次的資料可以有效減輕伺服器的負擔。

 

我們以前的對串聯功能表的處理多數是這樣的：

為了避免每次對菜單的操作引起的重載頁面，不採用每次調用背景方式，而是一次性將串聯功能表的所有資料全部讀取出來並寫入數組，然後根據使用者的操作用 JavaScript來控制它的子集項目的呈現，這樣雖然解決了操作響應速度、不重載頁面以及避免向伺服器頻繁發送請求的問題，但是如果使用者不對菜單進行 操作或只對菜單中的一部分進行操作的話，那讀取的資料中的一部分就會成為冗餘資料而浪費使用者的資源，特別是在菜單結構複雜、資料量大的情況下（比如菜單有 很多級、每一級菜又有上百個項目），這種弊端就更為突出。

如果在此案中應用Ajax後，結果就會有所改觀：

在初始化頁面時我們唯讀出它的第一級的所有資料並顯示，在使用者操作一級菜單其中一項時，會通過Ajax向後台請求當前一級項目所屬的二級子功能表的所有資料，如 果再繼續請求已經呈現的二級菜單中的一項時，再向後面請求所操作二級功能表項目對應的所有三級菜單的所有資料，以此類推……這樣，用什麼就取什麼、用多少就取 多少，就不會有資料的冗餘和浪費，減少了資料下載總量，而且更新頁面時不用重載全部內容，只更新需要更新的那部分即可，相對於幕後處理並重載的方式縮短了 使用者等待時間，也把對資源的浪費降到最低。

3.快速的使用者與使用者間的交流響應

在眾多人蔘與的交流討論的情境下，最不爽的事情就是讓使用者一遍又一遍重新整理頁面以便知道是否有新的討論出現。新的回複應該以最快的速度顯示出來，而把使用者從分神的重新整理中解脫出來，Ajax是最好的選擇。

4.類似投票、yes/no等無關痛癢的情境

對於類似這樣的情境中，如果提交過程需要達到40秒，很多的使用者就會直接忽略過去而不會參與，但是Ajax可以把時間控制在1秒之內，從而更多的使用者會加入進來。

5.對資料進行過濾和操縱相關資料的情境

對資料使用過濾器，按照時間排序，或者按照時間和名稱排序，開關過濾器等等。任何要求具備很高互動性資料操縱的場合都應該用JavaScript，而不是用一系列的伺服器請求來完成。在每次資料更新後，再對其進行尋找和處理需要耗費較多的時間，而Ajax可以加速這個過程。

6.普通的文本輸入提示和自動完成的情境

在文字框等輸入表單中給予輸入提示，或者自動完成，可以有效改善使用者體驗，尤其是那些自動完成的資料可能來自於伺服器端的場合，Ajax是很好的選擇。

Ajax不適用情境

1.部分簡單的表單

雖然表單提交可以從Ajax擷取最大的益處，但一個簡單的評論表單極少能從Ajax得到什麼明顯的改善。而一些較少用到的表單提交，Ajax則幫不上什麼忙。

2.搜尋

有些使用了Ajax的搜尋引擎如Start.com和Live.com不允許使用瀏覽器的後退按鈕來查看前一次搜尋的結果，這對已經養成搜尋習慣的使用者來說是不可原諒的。

現在Dojo通過iframe來解決這個問題。

3.基本的導航

使用Ajax來做網站內的導航是一個壞主意，為什麼不把時間放在讓系統程式作的更好上呢？

4.替換大量的文本

使用Ajax可以實現頁面的局部重新整理，但是如果頁面的每個部分都改變了，為什麼不重新做一次伺服器請求呢？

5.對呈現的操縱

Ajax看起來像是一個純粹的UI技術，但事實上它不是。它實際上是一個資料同步、操縱和傳輸的技術。對於可維護的乾淨的web應用，不使用Ajax來控制頁面呈現是一個不錯的主意。JavaScript可以很簡單的處理XHMTL/HTML/DOM，使用CSS規則就可以很好的表達資料顯示。

 

存在的問題

1.用JavaScript作的Ajax引擎，JavaScript的相容性和DeBug都是讓人頭痛的事；

2.Ajax的無重新整理重載，由於頁面的變化沒有重新整理重載那麼明顯，所以容易給使用者帶來困擾?D?D使用者不太清楚現在的資料是新的還是已經更新過的；現有的解決有：在相關位置提示、資料更新的地區設計得比較明顯、資料更新後給使用者提示等；

3.中間過程不能被bookmark。解決方案：GoogleMaps通過在頁面上提供一個”link to this page”的辦法來解決。另外，還可以通過url連結中加無效的?^標記來解決，但還未驗證。

AJAX架構

• DWR - web Remoting
• Buffalo - web Remoting (based on prototype)
• prototype - JS OO library
• openrico - JS UI component (based on prototype)
• dojo - JS library and UI component
• qooxdoo - JS UI component (C/S Style)
• YUL - JS UI component

web Remoting - DWR vs Buffalo

DWR和Buffalo都是Web Remoting架構，區別在於：

• DWR使用自訂的簡單文本協議，而Buffalo使用burlap協議。因此Buffalo解析大資料量可能會比較慢，然而可以適用於多種伺服器端和用戶端，並且burlap協議的完整性和支援的資料類型更加豐富
• Buffalo基於prototype，如果你的AJAX應用也是基於prototype，那麼可以減少重複載入prototype的頻寬，並且獲得相當一致的編程概念
• DWR的伺服器端實現要比Buffalo完善一些
• DWR更加通用一些，使用者比較廣，而Buffalo是國內的Michael寫的，使用者使用比較少(名氣較小)
• 建議使用buffalo，相對更加易用，然而伺服器端功能有待完善

JavaScript Component Library - prototype vs qooxdoo vs dojo vs YUL

• prototype是一個非常優雅的JS庫，定義了JS的物件導向擴充，DOM操作API，事件等等，之上還有rico/script.aculo.us實現一些JS組件功能和效果(不過目前還不是很完善)，以prototype為核心，形成了一個外圍的各種各樣的JS擴充庫，是相當有前途的JS底層架構，值得推薦，prototype以及rico/script.aculo.us的一個特出特點就是非常易學易用，門檻很低，常常是一兩行JS代碼就可以搞定一個相關的功能。同時它也是RoR整合的AJAX JS庫。

• qooxdoo是一個功能很強的JS組件庫，完全模仿Windows作業系統的GUI組件。特點是不通過常規的HTML來構造頁面，完全使用JS以類似VB/Delphi風格的編程方式構造Web GUI介面，比較適合內網面向C/S風格的web應用，，而不適合面向Internet的介面多變風格的應用。qooxdoo的一個重大賣點在於qooxdoo將要提供一個FormDesigner的IDE，通過在IDE裡面的可視化拖拽設計方式來自動產生C/S風格的web頁面js代碼。qooxdoo缺點是JS檔案體積過大，超過200KB，初次下載會比較慢，而且並不適合Internet消費類網站。

• dojo是一個各個方面相當完善的JS庫，包括了JS本身的語言擴充，以及各個方面的工具類庫，和比較完善的UI組件庫，也被廣泛應用在很多項目中，他的UI組件的特點是通過給html標籤增加tag的方式進行擴充，而不是通過寫JS來產生，dojo的API模仿Java類庫的組織方式。dojo的優點就是庫相當完善，發展時間也比較長，缺點是檔案體積也比較大，200多KB，初次下載相當慢，此外，dojo的類庫使用顯得不是那麼易用，至少給我的感覺是相當笨拙，特別是和prototype相比，更加顯得難用。

• YUL是Yahoo新近發布的AJAX組件庫，也是一個包含了各個方面，從工具類庫到通訊，到UI組件的綜合性JS庫。YUL的優勢在於文檔非常齊全，而且有Yahoo的支援，缺點是庫目前還是不是很全，功能也不強大。