Ajax技術(shù)全解之三
2024-09-01 08:30:34
供稿：網(wǎng)友
Ajax適用場(chǎng)景
1.表單驅(qū)動(dòng)的交互
傳統(tǒng)的表單提交，在文本框輸入內(nèi)容后，點(diǎn)擊按鈕，后臺(tái)處理完畢后，頁(yè)面刷新，再回頭檢查是否刷新結(jié)果正確。使用Ajax，在點(diǎn)擊sunmit按鈕后，立刻進(jìn)行異步處理，并在頁(yè)面上快速顯示了更新后的結(jié)果，這里沒(méi)有整個(gè)頁(yè)面刷新的問(wèn)題。
2.深層次的樹(shù)的導(dǎo)航
深層次的級(jí)聯(lián)菜單（樹(shù)）的遍歷是一項(xiàng)非常復(fù)雜的任務(wù)，使用JavaScript來(lái)控制顯示邏輯，使用Ajax延遲加載更深層次的數(shù)據(jù)可以有效的減輕服務(wù)器的負(fù)擔(dān)。
我們以前的對(duì)級(jí)聯(lián)菜單的處理多數(shù)是這樣的：
為了避免每次對(duì)菜單的操作引起的重載頁(yè)面，不采用每次調(diào)用后臺(tái)的方式，而是一次性將級(jí)聯(lián)菜單的所有數(shù)據(jù)全部讀取出來(lái)并寫(xiě)入數(shù)組，然后根據(jù)用戶的操作用 JavaScript來(lái)控制它的子集項(xiàng)目的呈現(xiàn)，這樣雖然解決了操作響應(yīng)速度、不重載頁(yè)面以及避免向服務(wù)器頻繁發(fā)送請(qǐng)求的問(wèn)題，但是如果用戶不對(duì)菜單進(jìn)行 操作或只對(duì)菜單中的一部分進(jìn)行操作的話，那讀取的數(shù)據(jù)中的一部分就會(huì)成為冗余數(shù)據(jù)而浪費(fèi)用戶的資源，特別是在菜單結(jié)構(gòu)復(fù)雜、數(shù)據(jù)量大的情況下（比如菜單有 很多級(jí)、每一級(jí)菜又有上百個(gè)項(xiàng)目），這種弊端就更為突出。
如果在此案中應(yīng)用Ajax后，結(jié)果就會(huì)有所改觀：
在初始化頁(yè)面時(shí)我們只讀出它的第一級(jí)的所有數(shù)據(jù)并顯示，在用戶操作一級(jí)菜單其中一項(xiàng)時(shí)，會(huì)通過(guò)Ajax向后臺(tái)請(qǐng)求當(dāng)前一級(jí)項(xiàng)目所屬的二級(jí)子菜單的所有數(shù)據(jù)，如 果再繼續(xù)請(qǐng)求已經(jīng)呈現(xiàn)的二級(jí)菜單中的一項(xiàng)時(shí)，再向后面請(qǐng)求所操作二級(jí)菜單項(xiàng)對(duì)應(yīng)的所有三級(jí)菜單的所有數(shù)據(jù)，以此類推……這樣，用什么就取什么、用多少就取 多少，就不會(huì)有數(shù)據(jù)的冗余和浪費(fèi)，減少了數(shù)據(jù)下載總量，而且更新頁(yè)面時(shí)不用重載全部?jī)?nèi)容，只更新需要更新的那部分即可，相對(duì)于后臺(tái)處理并重載的方式縮短了 用戶等待時(shí)間，也把對(duì)資源的浪費(fèi)降到最低。
3.快速的用戶與用戶間的交流響應(yīng)
在眾多人參與的交流討論的場(chǎng)景下，最不爽的事情就是讓用戶一遍又一遍刷新頁(yè)面以便知道是否有新的討論出現(xiàn)。新的回復(fù)應(yīng)該以最快的速度顯示出來(lái)，而把用戶從分神的刷新中解脫出來(lái)，Ajax是最好的選擇。
4.類似投票、yes/no等無(wú)關(guān)痛癢的場(chǎng)景
對(duì)于類似這樣的場(chǎng)景中，如果提交過(guò)程需要達(dá)到40秒，很多的用戶就會(huì)直接忽略過(guò)去而不會(huì)參與，但是Ajax可以把時(shí)間控制在1秒之內(nèi)，從而更多的用戶會(huì)加入進(jìn)來(lái)。
5.對(duì)數(shù)據(jù)進(jìn)行過(guò)濾和操縱相關(guān)數(shù)據(jù)的場(chǎng)景
對(duì)數(shù)據(jù)使用過(guò)濾器，按照時(shí)間排序，或者按照時(shí)間和名稱排序，開(kāi)關(guān)過(guò)濾器等等。任何要求具備很高交互性數(shù)據(jù)操縱的場(chǎng)合都應(yīng)該用JavaScript，而不是用一系列的服務(wù)器請(qǐng)求來(lái)完成。在每次數(shù)據(jù)更新后，再對(duì)其進(jìn)行查找和處理需要耗費(fèi)較多的時(shí)間，而Ajax可以加速這個(gè)過(guò)程。
6.普通的文本輸入提示和自動(dòng)完成的場(chǎng)景
在文本框等輸入表單中給予輸入提示，或者自動(dòng)完成，可以有效的改善用戶體驗(yàn)，尤其是那些自動(dòng)完成的數(shù)據(jù)可能來(lái)自于服務(wù)器端的場(chǎng)合，Ajax是很好的選擇。
Ajax不適用場(chǎng)景
1.部分簡(jiǎn)單的表單
雖然表單提交可以從Ajax獲取最大的益處，但一個(gè)簡(jiǎn)單的評(píng)論表單極少能從Ajax得到什么明顯的改善。而一些較少用到的表單提交，Ajax則幫不上什么忙。
2.搜索
有些使用了Ajax的搜索引擎如Start.com和Live.com不允許使用瀏覽器的后退按鈕來(lái)查看前一次搜索的結(jié)果，這對(duì)已經(jīng)養(yǎng)成搜索習(xí)慣的用戶來(lái)說(shuō)是不可原諒的。
現(xiàn)在Dojo通過(guò)iframe來(lái)解決這個(gè)問(wèn)題。
3.基本的導(dǎo)航
使用Ajax來(lái)做站點(diǎn)內(nèi)的導(dǎo)航是一個(gè)壞主意，為什么不把時(shí)間放在讓系統(tǒng)程序作的更好上呢？
4.替換大量的文本
使用Ajax可以實(shí)現(xiàn)頁(yè)面的局部刷新，但是如果頁(yè)面的每個(gè)部分都改變了，為什么不重新做一次服務(wù)器請(qǐng)求呢？
5.對(duì)呈現(xiàn)的操縱
Ajax看起來(lái)像是一個(gè)純粹的UI技術(shù)，但事實(shí)上它不是。它實(shí)際上是一個(gè)數(shù)據(jù)同步、操縱和傳輸?shù)募夹g(shù)。對(duì)于可維護(hù)的干凈的web應(yīng)用，不使用Ajax來(lái)控制頁(yè)面呈現(xiàn)是一個(gè)不錯(cuò)的主意。JavaScript可以很簡(jiǎn)單的處理XHMTL/HTML/DOM，使用CSS規(guī)則就可以很好的表達(dá)數(shù)據(jù)顯示。
存在的問(wèn)題
1.用JavaScript作的Ajax引擎，JavaScript的兼容性和DeBug都是讓人頭痛的事；
2.Ajax的無(wú)刷新重載，由于頁(yè)面的變化沒(méi)有刷新重載那么明顯，所以容易給用戶帶來(lái)困擾?D?D用戶不太清楚現(xiàn)在的數(shù)據(jù)是新的還是已經(jīng)更新過(guò)的；現(xiàn)有的解決有：在相關(guān)位置提示、數(shù)據(jù)更新的區(qū)域設(shè)計(jì)得比較明顯、數(shù)據(jù)更新后給用戶提示等；
3.中間過(guò)程不能被bookmark。解決方法：GoogleMaps通過(guò)在頁(yè)面上提供一個(gè)”link to this page”的辦法來(lái)解決。另外，還可以通過(guò)url鏈接中加無(wú)效的?^標(biāo)記來(lái)解決，但還未驗(yàn)證。
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框架，區(qū)別在于：
DWR使用自定義的簡(jiǎn)單文本協(xié)議，而B(niǎo)uffalo使用burlap協(xié)議。因此Buffalo解析大數(shù)據(jù)量可能會(huì)比較慢，然而可以適用于多種服務(wù)器端和客戶端，并且burlap協(xié)議的完整性和支持的數(shù)據(jù)類型更加豐富
Buffalo基于prototype，如果你的AJAX應(yīng)用也是基于prototype，那么可以減少重復(fù)加載prototype的帶寬，并且獲得相當(dāng)一致的編程概念
DWR的服務(wù)器端實(shí)現(xiàn)要比Buffalo完善一些
DWR更加通用一些，用戶比較廣，而B(niǎo)uffalo是國(guó)內(nèi)的Michael寫(xiě)的，用戶使用比較少(名氣較小)
建議使用buffalo，相對(duì)更加易用，然而服務(wù)器端功能有待完善
JavaScript Component Library - prototype vs qooxdoo vs dojo vs YUL
prototype是一個(gè)非常優(yōu)雅的JS庫(kù)，定義了JS的面向?qū)ο髷U(kuò)展，DOM操作API，事件等等，之上還有rico/script.aculo.us實(shí)現(xiàn)一些JS組件功能和效果(不過(guò)目前還不是很完善)，以prototype為核心，形成了一個(gè)外圍的各種各樣的JS擴(kuò)展庫(kù)，是相當(dāng)有前途的JS底層框架，值得推薦，prototype以及rico/script.aculo.us的一個(gè)特出特點(diǎn)就是非常易學(xué)易用，門(mén)檻很低，常常是一兩行JS代碼就可以搞定一個(gè)相關(guān)的功能。同時(shí)它也是RoR集成的AJAX JS庫(kù)。
qooxdoo是一個(gè)功能很強(qiáng)的JS組件庫(kù)，完全模仿Windows操作系統(tǒng)的GUI組件。特點(diǎn)是不通過(guò)常規(guī)的HTML來(lái)構(gòu)造頁(yè)面，完全使用JS以類似VB/Delphi風(fēng)格的編程方式構(gòu)造Web GUI界面，比較適合內(nèi)網(wǎng)面向C/S風(fēng)格的web應(yīng)用，，而不適合面向Internet的界面多變風(fēng)格的應(yīng)用。qooxdoo的一個(gè)重大賣(mài)點(diǎn)在于qooxdoo將要提供一個(gè)FormDesigner的IDE，通過(guò)在IDE里面的可視化拖拽設(shè)計(jì)方式來(lái)自動(dòng)生成C/S風(fēng)格的web頁(yè)面js代碼。qooxdoo缺點(diǎn)是JS文件體積過(guò)大，超過(guò)200KB，初次下載會(huì)比較慢，而且并不適合Internet消費(fèi)類網(wǎng)站。
dojo是一個(gè)各個(gè)方面相當(dāng)完善的JS庫(kù)，包括了JS本身的語(yǔ)言擴(kuò)展，以及各個(gè)方面的工具類庫(kù)，和比較完善的UI組件庫(kù)，也被廣泛應(yīng)用在很多項(xiàng)目中，他的UI組件的特點(diǎn)是通過(guò)給html標(biāo)簽增加tag的方式進(jìn)行擴(kuò)展，而不是通過(guò)寫(xiě)JS來(lái)生成，dojo的API模仿Java類庫(kù)的組織方式。dojo的優(yōu)點(diǎn)就是庫(kù)相當(dāng)完善，發(fā)展時(shí)間也比較長(zhǎng)，缺點(diǎn)是文件體積也比較大，200多KB，初次下載相當(dāng)慢，此外，dojo的類庫(kù)使用顯得不是那么易用，至少給我的感覺(jué)是相當(dāng)笨拙，特別是和prototype相比，更加顯得難用。
YUL是Yahoo新近發(fā)布的AJAX組件庫(kù)，也是一個(gè)包含了各個(gè)方面，從工具類庫(kù)到通訊，到UI組件的綜合性JS庫(kù)。YUL的優(yōu)勢(shì)在于文檔非常齊全，而且有Yahoo的支持，缺點(diǎn)是庫(kù)目前還是不是很全，功能也不強(qiáng)大。
