互聯(lián)網(wǎng)ajax基礎(chǔ)教程

1、 Ajax 基礎(chǔ)教程 制作：badnewfish 聯(lián)系： 1.2 瀏覽器歷史 提到 Web 瀏覽器，大多數(shù)人都會想到無處不在的Microsoft Internet Explorer ，直到最 像 Firefox 、Safari 和 Opera 之類的瀏覽器日益興起，這種情況才稍有改觀。許多新手可能會 誤認為 IE 是市場上的第一個瀏覽器，其實不然。實際上，第一個Web 瀏覽器出自Berners Lee 之手，這是他為NeXT 計算機創(chuàng)建的（這個 Web 瀏覽器原來取名叫WorldWideWeb ，后 來改名為Nexus ），并在 1990 年發(fā)布給 CERN 的人員使用。Berners-Lee

2、 和 Jean-Francois Groff 將 WorldWideWeb 移植到 C，并把這個瀏覽器改名為libwww 。20 世紀 90 年代初出現(xiàn) 了許多瀏覽器，包括Nicola Pellow 編寫的行模式瀏覽器（這個瀏覽器允許任何系統(tǒng)的用戶都 能訪問Internet ，從Unix 到Microsoft DOS 都涵蓋在內(nèi)），還有 Samba，這是第一個面向 Macintosh 的瀏覽器。 1993 年 2 月，伊利諾伊大學(xué)Urbana-Champaign 分校美國國家超級計算應(yīng)用中心的Marc Andreessen 和 Eric Bina 發(fā)布了Unix 版本的 Mosaic 。幾個月

3、之后，Aleks Totic 發(fā)布了Mosaic 的Macintosh 版本，這使得 Mosaic 成為第一個跨平臺瀏覽器，它很快得到普及，并成為最流 行的 Web 瀏覽器1。這項技術(shù)后來賣給了Spyglass ，最后又歸入Microsoft 的門下，并應(yīng)用 在 Internet Explorer 中。 1993 年，堪薩斯大學(xué)的開發(fā)人員編寫了一個基于文本的瀏覽器，叫做 Lynx ，它成為了 字符終端的標準。1994 年，挪威奧斯陸的一個小組開發(fā)了 Opera，到 1996 年這個瀏覽器得 到了廣泛使用。1994 年 12 月，Netscape 發(fā)布了Mozilla 的 1.0 版，第一個盈利

4、性質(zhì)的瀏覽器 從此誕生。2002 年又發(fā)布了一個開源的版本，這最終發(fā)展為 2004 年 11 月發(fā)布的、現(xiàn)在十分 流行的 Firefox 瀏覽器。 當Microsoft 發(fā)布Windows 95 時，IE 1.0 是作為Microsoft Plus!包的一部分同時發(fā)布的。 盡管這個瀏覽器與操作系統(tǒng)集成在一起，但大多數(shù)人還是堅持使用Netscape 、Lynx 或 Opera 。IE 2.0 有了很大起色，增加了對 cookie、安全套接字層（Secure Socket Layer ，SSL ） 和其他新興標準的支持。2.0 版還可以用于 Macintosh ，從而成為Microsoft 的第一

5、個跨平臺 瀏覽器。不過，大多數(shù)用戶還是很執(zhí)著，仍然堅持使用他們習(xí)用的瀏覽器。 不過到了 1996 年夏天，Microsoft 發(fā)布了 IE 3.0 版。幾乎一夜之間，人們紛紛擁向 IE 。 當時，Netscape 的瀏覽器是要收費的，Microsoft 則免費提供IE 。關(guān)于瀏覽器領(lǐng)域誰主沉浮， 因特網(wǎng)社區(qū)發(fā)生了兩極分化，很多人擔(dān)心Microsoft 會像在桌面領(lǐng)域一樣，在Web 領(lǐng)域也一 統(tǒng)天下。有些人則考慮到安全因素果然不出所料，發(fā)布3.0 版 9 天之后就報告了第一個 安全問題。但是到 1999 年發(fā)布 IE 5 時，它已經(jīng)成為使用最廣的瀏覽器。 1.3 Web 應(yīng)用的發(fā)展歷程 最初，所

6、有 Web 頁面都是靜態(tài)的，用戶請求一個資源，服務(wù)器再返回這個資源。什么都不 動，什么都不閃。坦率地講，對于許多Web 網(wǎng)站來說，這樣也是可以的，這些網(wǎng)站的Web 頁面只是電子形式的文本，在一處生成，內(nèi)容固定，再發(fā)布到多處。在瀏覽器發(fā)展的最初階 段，Web 頁面的這種靜態(tài)性不成問題，科學(xué)家只是使用因特網(wǎng)來交換研究論文，大學(xué)院校也 只是通過因特網(wǎng)在線發(fā)布課程信息。企業(yè)界還沒有發(fā)現(xiàn)這個新 “渠道”會提供什么商機。實 際上，以前公司主頁顯示的信息通常很少，無非是一些聯(lián)系信息或者只是一些文檔。不過沒 過多久，Web 用戶就開始有新的要求了，希望能得到更動態(tài)的網(wǎng)上體驗。個人計算機成為企 業(yè)不可或缺的資源

7、，而且從個人宿舍到住家辦公室開始出現(xiàn)越來越多的計算機。隨著 Windows 95 的問世，隨著人們已經(jīng)領(lǐng)教了 Corel WordPerfect 和 Microsoft Excel 豐富的功能， 用戶的期望也越來越高。 1.3.1 CGI 要讓W(xué)eb 更為動態(tài)，第一個辦法是公共網(wǎng)關(guān)接口 （Common Gateway Interface ，CGI ）。 與靜態(tài)的Web 獲取不同，使用 CGI 可以創(chuàng)建程序，當用戶發(fā)出請求時就會執(zhí)行這個程序。 假設(shè)要在 Web 網(wǎng)站上顯示銷售的商品，你可以利用 CGI 腳本來訪問商品數(shù)據(jù)庫，并顯示結(jié) 果。通過使用簡單的HTML 表單和 CGI 腳本，可以創(chuàng)建簡單

8、的網(wǎng)上店面，這樣別人就可以 通過瀏覽器來購買商品。編寫CGI 腳本可以用多種語言，從Perl 到Visual Basic 都可以，這 使得掌握不同編程語言的人都能編寫CGI 腳本。 不過，要創(chuàng)建動態(tài)的Web 頁面，CGI 并不是最安全的方法。如果采用 CGI，將允許別人 在你的系統(tǒng)上執(zhí)行程序。大多數(shù)情況下這可能沒有問題，但是倘若某個用戶有惡意企圖，則 很可能會利用這一點，讓系統(tǒng)運行你本來不想運行的程序。盡管存在這個缺陷，到如今CGI 仍在使用。 1.3.2 applet 很顯然，CGI 可以有所改進。1995 年 5 月，Sun 公司的John Gage 和 Andreessen （目前在 N

9、etscape 通信公司）宣布一種新的編程語言誕生，這就是Java 。Netscape Navigator 為這種新 語言提供了支持，最初是為了支持機頂盒。（你可能原認為最早涉足智能家居的公司是 Microsoft 和 Sony 其實不然。）就像所有革命都機緣巧合一樣，Java 和因特網(wǎng)的出現(xiàn)恰到好 處，在適當?shù)臅r間、適當?shù)牡攸c橫空出世，Java 在 Web 上發(fā)布僅幾個月，就已經(jīng)有成千上 萬的人下載。由于Netscape 的Navigator 支持 Java ，動態(tài)Web 頁面掀開了新的一頁：applet 時代到來了。 applet 允許開發(fā)人員編寫可嵌入在 Web 頁面上的小應(yīng)用程序。只要

10、用戶使用支持 Java 的 瀏覽器，就可以在瀏覽器的 Java 虛擬機（Java Virtual Machine ，JVM ）中運行 applet 。盡管 applet 可以做很多事情，但它也存在一些限制：通常不允許它讀寫文件系統(tǒng)，它也不能加載 本地庫，而且可能無法啟動客戶端上的程序。除了這些限制外，applet 是在一個沙箱安全模 型中運行的，這是為了有助于防止用戶運行惡意代碼。 對許多人來說，最初接觸Java 編程語言就是從 applet 開始的，當時這是創(chuàng)建動態(tài)Web 應(yīng) 用的一種絕好的方法。applet 允許你在瀏覽器中創(chuàng)建一個胖客戶應(yīng)用，不過要在平臺的安全 限制范圍內(nèi)。當時，在很多領(lǐng)

11、域都廣泛使用了applet，但是，Web 社區(qū)并沒有完全被applet“ 征服”2。胖客戶的開發(fā)人員都很熟悉一個問題：必須在客戶端上部署適當?shù)腏ava 版本。 因為applet 在瀏覽器的虛擬機中運行，所以開發(fā)人員必須確?？蛻舳税惭b了適當版本的 Java 。盡管這個問題也可以解決，但它確實妨礙了applet 技術(shù)的進一步推廣。而且如果 applet 寫得不好，很可能對客戶主機造成影響，這使許多客戶對于是否采用基于 applet 的解 決方案猶豫不定。如果你還不太熟悉applet，請看圖1-1，圖中顯示了Sun 公司提供的時鐘 applet 。 圖1-1Sun 的時鐘applet 1.3.3 J

12、avaScript 與此同時，Netscape 創(chuàng)建了一種腳本語言，并最終命名為 JavaScript （建立原型時叫做 Mocha ，正式發(fā)布之前曾經(jīng)改名為LiveWire 和 LiveScript ，不過最后終于確定為 JavaScript ）。設(shè)計 JavaScript 是為了讓不太熟悉Java 的Web 設(shè)計人員和程序員能夠更輕松 地開發(fā) applet （當然，Microsoft 也推出了與JavaScript 相對應(yīng)的腳本語言，稱為 VBScript ）。Netscape 請Brendan Eich 來設(shè)計和實現(xiàn)這種新語言，他認為市場需要的是一種 動態(tài)類型腳本語言。由于缺乏開發(fā)工具，

13、缺少有用的錯誤消息和調(diào)試工具，JavaScript 很受 非議，但盡管如此，JavaScript 仍然是一種創(chuàng)建動態(tài)Web 應(yīng)用的強大方法。 最初，創(chuàng)建 JavaScript 是為了幫助開發(fā)人員動態(tài)地修改頁面上的標記，以便為客戶提供 更豐富的體驗。人們越來越認識到，頁面也可以當作對象，因此文檔對象模型 （Document Object Model ，DOM ）應(yīng)運而生。剛開始，JavaScript 和 DOM 緊密地交織在一起，但最后它 們還是 “分道揚鑣”，并各自發(fā)展。DOM 是頁面的一個完全面向?qū)ο蟮谋硎荆擁撁婵梢?用某種腳本語言 （如JavaScript 或VBScript ）進行修改

14、。 最后，萬維網(wǎng)協(xié)會（World Wide Web Consortium ，W3C ）介入，并完成了 DOM 的標準 化，而歐洲計算機制造商協(xié)會（ECMA ）批準 JavaScript 作為 ECMAScript 規(guī)約。根據(jù)這些標 準編寫的頁面和腳本，在遵循相應(yīng)原則的任何瀏覽器上都應(yīng)該有相同的外觀和表現(xiàn)。 在最初的幾年中，JavaScript 的發(fā)展很是坎坷，這是許多因素造成的。首先，瀏覽器支持 很不一致，即使是今天，同樣的腳本在不同瀏覽器上也可能有不同的表現(xiàn)；其次，客戶可以 自由地把 JavaScript 關(guān)閉，由于存在一些已知的安全漏洞，往往鼓勵用戶把 JavaScript 關(guān)掉。 由于開

15、發(fā)JavaScript 很有難度 （你會用 alert 嗎？），許多開發(fā)人員退避三舍，有些開發(fā)人員 干脆不考慮 JavaScript ，認為這是圖形設(shè)計人員使用的一種 “玩具”語言。許多人曾試圖使 用、 試和調(diào)試復(fù)雜的JavaScript ，并為此身心俱疲，所以大多數(shù)人在經(jīng)歷了這種痛苦之后， 最終只能滿足于用JavaScript 創(chuàng)建簡單的基于表單的應(yīng)用。 1.3.4 servlet、ASP 和 PHP哦，太多了！ 盡管 applet 是基于Web 的，但胖客戶應(yīng)用存在的許多問題在 applet 上也有所體現(xiàn)。在大 量使用撥號連接的年代（就算是今天，撥號連接也很普遍），要下載一個復(fù)雜apple

16、t 的完整 代碼，要花很多時間，用戶不能承受。開發(fā)人員還要考慮客戶端上的 Java 版本，有些虛擬 機還有更多的要求3。理想情況下只需提供靜態(tài)的Web 頁面就夠了，畢竟，這正是設(shè)計因 特網(wǎng)的本來 目的。當然，盡管靜態(tài)頁面是靜態(tài)的，但是如果能在服務(wù)器上動 態(tài) 地生成內(nèi)容， 再把靜態(tài)的內(nèi)容返回，這就太好了。 在 Java 問世一年左右，Sun 引入了 servlet ?，F(xiàn)在Java 代碼不用再像 applet 那樣在客戶端 瀏覽器中運行了，它可以在你控制的一個應(yīng)用服務(wù)器上運行。這樣，開發(fā)人員就能充分利用 現(xiàn)有的業(yè)務(wù)應(yīng)用，而且，如果需要升級為最新的Java 版本，只需要考慮服務(wù)器就行了。Java 推

17、崇 “一次編寫，到處運行”，這一點使得開發(fā)人員可以選擇最先進的應(yīng)用服務(wù)器和服務(wù)器 環(huán)境，這也是這種新技術(shù)的另一個優(yōu)點。servlet 還可以取代 CGI 腳本。 servlet 向前邁出了很大一步。servlet 提供了對整個 Java 應(yīng)用編程接口 （API ）的完全訪 問，而且提供了一個完備的庫可以處理HTTP 。不過，servlet 不是十全十美的。使用 servlet 設(shè)計界面可能很困難。在典型的servlet 交互中，先要從用戶那里得到一些信息，完成某種業(yè) 務(wù)邏輯，然后使用一些“打印行”創(chuàng)建 HTML ，為用戶顯示結(jié)果。代碼清單1-1 所示的代碼 就相當常見。 代碼清單1-1簡單的s

18、ervlet 代碼 response.setContentType(text/html;charset=UTF 8); PrintWriter out = response.getWriter(); out.println(); out.println(); out.println(Servlet SimpleServlet); out.println(); out.println(); out.println(Hello World); out.println(Imagine if this were more complex.); out.println(); out.println();

19、 out.close(); 以上這一小段代碼可以生成圖1-2 所示的一個相當簡單的Web 頁面。 圖1-2代碼清單1-1 中簡單servlet 的輸出 servlet 不 僅容易出錯，很難生成可視化顯示，而且還無法讓開發(fā)者盡展其才。一般地， 編寫服務(wù)器端代碼的人往往是軟件開發(fā)人員，他們只是對算法和編譯器很精通，但不是 能 設(shè)計公司精美網(wǎng)站的圖形設(shè)計人員。業(yè)務(wù)開發(fā)人員不僅要編寫業(yè)務(wù)邏輯，還必須考慮怎么創(chuàng) 建一致的設(shè)計。因此，很有必要將表示與業(yè)務(wù)邏輯分離。因此JSP （JavaServer Pages ）出現(xiàn) 了。 在某種程度上，JSP 是對 Microsoft 的 Active Server P

20、ages (ASP ）做出的回應(yīng)。Microsoft 從 Sun 在 servlet 規(guī)約上所犯的錯誤汲取了教訓(xùn)，并創(chuàng)建了ASP 來簡化動態(tài)頁面的開發(fā)。 Microsoft 增加了非常好的工具支持，并與其 Web 服務(wù)器緊密集成。JSP 和 ASP 的設(shè)計 目的 都是為了將業(yè)務(wù)處理與頁面外觀相分離，從這個意義上講，二者是相似的。雖然存在一些技 術(shù)上的差別 （Sun 也從Microsoft 那里學(xué)到了教訓(xùn)），但它們有一個最大的共同點，即Web 設(shè)計人員能夠?qū)Ｐ脑O(shè)計頁面外觀，而軟件開發(fā)人員可以專心開發(fā)業(yè)務(wù)邏輯。代碼清單1-2 顯 示了一個簡單的JSP 。 代碼清單1-2簡單的JSP Hello W

21、orld Hello World This code is more familiar for Web developers. 這個代碼會生成圖1-3 所示的輸出。 圖1-3簡單JSP 的輸出 當然，Microsoft 和 Sun 并沒有壟斷服務(wù)器端解決方案。還有許多其他的方案在這個領(lǐng)域 都有一席之地，如PHP 和 ColdFusion 等等。有些開發(fā)人員喜歡新奇的工具，還有一些則傾 向于更簡單的語言。目前來看，所有這些解決方案完成的任務(wù)都是一樣的，它們都是要動態(tài) 生成HTML 。在服務(wù)器端生成內(nèi)容可以解決發(fā)布問題。不過，與使用胖客戶或 applet 所做的 工作相比，用戶從原始HTML 得到

22、的體驗就太過單調(diào)和蒼白了。下面幾節(jié)將介紹幾種力圖 提供更豐富用戶體驗的解決方案。 1.3.5 Flash 并不是只有 Microsoft 和 Sun 在努力尋找辦法來解決動態(tài)Web 頁面問題。1996 年夏天， FutureWave 發(fā)布了一個名叫FutureSplash Animator 的產(chǎn)品。這個產(chǎn)品起源于一個基于 Java 的 動畫播放器，F(xiàn)utureWave 很快被Macromedia 兼并，Macromedia 則將這個產(chǎn)品改名為 Flash 。 利用 Flash ，設(shè)計人員可以創(chuàng)建令人驚嘆的動態(tài)應(yīng)用。公司可以在Web 上發(fā)布高度交互 性的應(yīng)用，幾乎與胖客戶應(yīng)用相差無幾（見圖1-4

23、）。不同于applet、servlet 和 CGI 腳本， Flash 不需要編程技巧，很容易上手。在 20 世紀 90 年代末期，掌握Flash 是一個很重要的特 長，因為許多老板都非常需要有這種技能的員工。不過，這種易用性也是有代價的。 圖1-4Flash 應(yīng)用 像許多解決方案一樣，F(xiàn)lash 需要客戶端軟件。盡管許多流行的操作系統(tǒng)和瀏覽器上都內(nèi) 置有所需的Shockwave 播放器插件，但并非普遍都有。雖然能免費下載，但由于擔(dān)心感染病 毒，使得許多用戶都拒絕安裝這個軟件。Flash 應(yīng)用可能還需要大量網(wǎng)絡(luò)帶寬才能正常地工 作，另外，由于沒有廣泛的寬帶連接，F(xiàn)lash 的推廣受到局限 （因

24、此產(chǎn)生了 “跳過本頁”之 類的鏈接）。雖然確有一些網(wǎng)站選擇建立多個版本的Web 應(yīng)用，分別適應(yīng)于不同的連接速 度，但是許多公司都無法承受支持兩個或更多網(wǎng)站所增加的開發(fā)開銷。 總之，創(chuàng)建 Flash 應(yīng)用需要專用的軟件和瀏覽器插件。applet 可以用文本編輯器編寫，而 且有一個免費的 Java 開發(fā)包，F(xiàn)lash 則不同，使用完整的Flash 工具包需要按用戶數(shù)付費，每 個用戶需要數(shù)百美元。盡管這些因素不是難以逾越的障礙，但它們確實減慢了Flash 在動態(tài) Web 應(yīng)用道路上的前進腳步。 1.3.6 DHTML 革命 當Microsoft 和Netscape 發(fā)布其各自瀏覽器的第4 版時，We

25、b 開發(fā)人員有了一個新的選擇： 動態(tài)HTML （Dynamic HTML ，DHTML ）。與有些人想像的不同 DHTML 不是一個W3C 標 準，它更像是一種營銷手段。實際上，DHTML 結(jié)合了HTML 、層疊樣式表 （Cascading Style Sheets ，CSS ）、JavaScript 和 DOM 。這些技術(shù)的結(jié)合使得開發(fā)人員可以動態(tài)地修改 Web 頁面的內(nèi)容和結(jié)構(gòu)。 最初 DHTML 的反響很好。不過，它需要的瀏覽器版本還沒有得到廣泛采用。盡管 IE 和 Netscape 都支持DHTML ，但是它們的實現(xiàn)大相徑庭，這要求開發(fā)人員必須知道他們的客戶 使用什么瀏覽器。而這通常意

26、味著需要大量代碼來檢查瀏覽器的類型和版本，這就進一步增 加了開發(fā)的開銷。有些人對于嘗試這種方法很是遲疑，因為DHTML 還沒有一個官方的標準。 不過，將來新標準有可能會出現(xiàn)。 1.3.7 XML 衍生語言 20 世紀 90 年代中期，基于SGML 衍生出了W3C 的可擴展標記語言 （eXtensible Markup Language ，XML ），自此以后，XML 變得極為流行。許多人把XML 視為解決所有計算機 開發(fā)問題的靈丹妙藥，以至于XML 幾乎無處不在。實際上，Microsoft 就已經(jīng)宣布，Office 12 將支持 XML 文件格式。 如今，我們至少有 4 種 XML 衍生語言可

27、以用來創(chuàng)建Web 應(yīng)用（W3C 的XHTML 不包括 在內(nèi)）：Mozilla 的XUL ；XAMJ ，這是結(jié)合Java 的一種開源語言；Macromedia 的MXML ； Microsoft 的XAML 。 XUL ：XUL （讀作 “zool” ）代表XML 用戶界面語言 （XML User Interface Language ），由Mozilla 基金會推出。流行的Firefox 瀏覽器和 Thunderbird 郵件客戶端都 是用XUL 編寫的。利用XUL ，開發(fā)人員能構(gòu)建功能很豐富的應(yīng)用，這個應(yīng)用可以與因 特網(wǎng)連接，也可以不與因特網(wǎng)連接。為了方便那些熟悉DHTML 的開發(fā)人員使用，

28、XUL 設(shè)計為可以跨平臺支持諸如窗口和按鈕等標準界面部件。雖然XUL 本身不是標準，但 它是基于各種標準的，如HTML 4.0 、CSS、DOM、XML 和 ECMAScript 等等。XUL 應(yīng) 用可以在瀏覽器上運行，也可以安裝在客戶端主機上。 當然，XUL 也不是沒有缺點。它需要 Gecko 引擎，而且目前IE 還沒有相應(yīng)的插件。 盡管 Firefox 在瀏覽器市場中已經(jīng)有了一定的份額，但少了IE 的支持還是影響很大，大 多數(shù)應(yīng)用都無法使用XUL 。目前開展的很多項目都是力圖在多個平臺上使用 XUL ，包 括 Eclipse 。 XAML ：XAML （讀作 “zammel” ）是Micr

29、osoft 即將推出的操作系統(tǒng)（名為 Windows Vista ）的一個組件。XAML 是可擴展應(yīng)用標記語言 （eXtensible Application Markup Language ）的縮寫，它為使用Vista 創(chuàng)建用戶界面定義了標準。與HTML 類似， XAML 使用標記來創(chuàng)建標準元素，如按鈕和文本框等。XAML 建立在 Microsoft 的 .NET 平臺之上，而且可以編譯為 .NET 類。 XAML 的局限應(yīng)當很清楚。作為Microsoft 的產(chǎn)品，它要求必須使用 Microsoft 的操 作系統(tǒng)。多數(shù)情況下特別是在大公司中，這可能不成問題，但是有些小公司使用的不是 Micr

30、osoft 的操作系統(tǒng)，總不能削足適履吧，就像是沒有哪家公司會因為買家沒有開某種 牌子的車來就把他拒之門外。Vista 交付的日期一再推遲，與此同時XAML 也有了很大 變化，不再只是一個播放器。據(jù)說，在未來幾年內(nèi)，我們可能會看到一個全新的 XAML 。 MXML ：Macromedia 創(chuàng)建了 MXML ，作為與其Flex 技術(shù)一同使用的一種標記語言。 MXML 是最佳體驗標記語言 （Maximum eXperience Markup Language ）的縮寫，它與 HTML 很相似，可以以聲明的方式來設(shè)計界面。與XUL 和 XAML 類似，MXML 提供了 更豐富的界面組件，如DataG

31、rid 和 TabNavigator，利用這些組件可以創(chuàng)建功能豐富的因 特網(wǎng)應(yīng)用。不過，MXML 不能獨立使用，它依賴于Flex 和 ActionScript 編程語言來編寫 業(yè)務(wù)邏輯。 MXML 與Flash 有同樣的一些限制。它是專用的，而且依賴于價格昂貴的開發(fā)和部 署環(huán)境。盡管將來.NET 可能會對 MXML 提供支持，但現(xiàn)在 Flex 只能在J2EE 應(yīng)用服務(wù) 器上運行，如Tomcat 和 IBM 的WebSphere ，這就進一步限制了 MXML 的廣泛采用。 XAMJ ：讓人欣喜的是，開源社區(qū)又向有關(guān)界面設(shè)計的 XML 衍生語言領(lǐng)域增加了新 的成員。XAMJ 作為另一種跨平臺的語言

32、，為Web 應(yīng)用開發(fā)人員又提供了一個工具。這 種衍生語言基于 Java ，而Java 是當前最流行的面向?qū)ο笳Z言之一，XAMJ 也因此獲得了 面向?qū)ο笳Z言的強大功能。XAMJ 實際上想要替代基于 XAML 或HTML 的應(yīng)用，力圖 尋找一種更為安全的方法，既不依賴于某種特定的框架，也不需要高速的因特網(wǎng)連接。 XAMJ 是一種編譯型語言，建立在 “clientlet” （小客戶端）體系結(jié)構(gòu)之上，盡管基于 XAMJ 的程序也可以是獨立的應(yīng)用，但通常都是基于Web 的應(yīng)用。在撰寫本書時， XAMJ 還太新，我們還沒有聽到太多批評的聲音。不過，批評是肯定會有的，讓我們拭 目以待。 當談到 “以X 開頭

33、的東西”時，別忘了W3C XForms 規(guī)約。XForms 設(shè)計為支持更豐富 的用戶界面，而且能夠?qū)?shù)據(jù)與表示解耦合。毋庸置疑，XForms 數(shù)據(jù)是XML ，這樣你就能 使用現(xiàn)有的XML 技術(shù)，如XPath 和 XML Schema 。標準HTML 能做的，XForms 都能做，而 且XForms 還有更多功能，包括動態(tài)檢查域值、與Web 服務(wù)集成等等。不同于其他的許多 W3C 規(guī)約，XForms 不需要新的瀏覽器，你可以使用現(xiàn)在已有的許多瀏覽器去實現(xiàn)。與大多 數(shù)XML 衍生語言一樣，XForms 是一種全新的方法，所以它要得到采納尚需時日。 1.3.8 基本問題 有了以上了解，你怎么想？即使

34、是要求最苛刻的客戶應(yīng)用，也已經(jīng)把 Web 作為首選平臺。 很顯然，基于 Web 的應(yīng)用很容易部署，這種低門檻正是Web 應(yīng) 用最耀眼的地方。由于瀏覽 器無處不在，而且無需下載和安裝新的軟件，用戶利用基于瀏覽器的客戶端就能很輕松地嘗 試新的應(yīng)用。用戶只需點擊一個鏈接就能運行 你的應(yīng)用程序，而不用先下載幾兆比特的安 裝程序才行?；跒g覽器的應(yīng)用也不考慮操作系統(tǒng)是什么，也就是說，不僅使用不同操作系 統(tǒng)（如Linux 和 Mac OS X ）的人能運行你的應(yīng)用程序，而且你也不必考慮針對不同的操作 系統(tǒng)開發(fā)和維護多個安裝包。 既然基于 Web 的應(yīng)用是前所未有的好東西，那我們?yōu)槭裁催€要寫這本書？如果回頭

35、看看 因特網(wǎng)的起源就可以知道，最初因特網(wǎng)實際上就是為了科學(xué)家們和學(xué)術(shù)機構(gòu)間交換文章和研 究成果，這是一種簡單的請求/ 響應(yīng)模式。那時不需要會話狀態(tài)，也不需要購物車，人們只 是在交換文檔。但現(xiàn)在你有很多辦法來創(chuàng)建動態(tài)的Web 應(yīng)用，如果想讓應(yīng)用真正深入人心， 贏得大量的用戶，就必須在瀏覽器上大做文章，這說明，因特網(wǎng)以請求/ 響應(yīng)模式作為基礎(chǔ)， 由此帶來的同步性對你造成了妨礙。 與Microsoft Word 或 Intuit Quicken 之類的胖客戶應(yīng)用相比，Web 模型當然只能根據(jù)一般 用戶需要做折中考慮。不過，由于Web 應(yīng)用很容易部署，而且瀏覽器的發(fā)展相當迅速，這 意味著大多數(shù)用戶都已

36、經(jīng)學(xué)會了適應(yīng)。但是，還是有許多人認為 Web 應(yīng)用只能算 “二等公 民”，給人的用戶體驗不是太好。因為因特網(wǎng)是一個同步的請求/ 響應(yīng)系統(tǒng)，所以瀏覽器中 的整個頁面會進行刷新。最初，這種簡單的請求并沒有什么問題。如果用戶做了一兩處修改， 就必須向服務(wù)器發(fā)回整個文檔，而且要重新繪制整個頁面。盡管這樣是可行的，但是這種完 全刷新的局限，意味著應(yīng)用確實還很粗糙。 這并不是說開發(fā)人員只是袖手旁觀，全然接受這種狀況。Microsoft 對于交互式應(yīng)用有一 定了解，而且對于這種標準請求/ 響應(yīng)模式的限制一直都不滿意，因此提出了遠程腳本 （remote scripting ）的概念。遠程腳本看似神奇，其實很簡

37、單：它允許開發(fā)人員創(chuàng)建以異步 方式與服務(wù)器交互的頁面。例如，顧客可以從下拉列表中選擇狀態(tài)，這樣就會在服務(wù)器上運 行一個腳本，計算顧客的運費。更重要的是，顯示這些運費時無需刷新整個面！當然， Microsoft 的方案只適用于它自己的技術(shù)，而且需要 Java ，但有了這個進步，說明更豐富的瀏 覽器應(yīng)用并不是海市蜃樓。 對于同步頁面刷新問題還有其他一些解決方案。針對 Microsoft 的遠程腳本，Brent Ashley 在創(chuàng)建 JavaScript 遠程腳本（JavaScript Remote Scripting ，JSRS ）時開發(fā)了一個平臺 中立 （獨立于平臺）的方案。JSRS 依賴于一個

38、客戶端 JavaScript 庫和 DHTML ，可以向服務(wù) 器做異步的調(diào)用。與此同時，許多人利用了 IFRAME 標記，可以只加載頁面中的某些部分， 或者向服務(wù)器做 “隱藏”的調(diào)用。盡管這是一個可行的方法，而且也為很多人所用，但它肯 定不是最理想的，還有待改善。 1.3.9 Ajax 終于談到這里了：客戶希望得到一個功能更完備的應(yīng)用，而開發(fā)人員想避開繁瑣的部署 工作，不想把可執(zhí)行文件逐個地部署到數(shù)以千計的工作站上。我們已經(jīng)做過很多嘗試，但是 任何方法都不像它原來標榜的那么完美。不過，最近一個極其強大的工具橫空出世了。 是的，我們又有了一個新的選擇，新的工具，可以創(chuàng)建的確豐富的基于瀏覽器的應(yīng)用

39、。 這就是Ajax 。Ajax 不只是一個特定的技術(shù)，更應(yīng)算是一種技巧，不過前面提到的 JavaScript 是其主要組件。我們知道，你可能會說“JavaScript 根本不值一提”，但是由于Ajax 的出現(xiàn)， 人們對這種語言又有了新的興趣，應(yīng)用和 試框架再加上更優(yōu)秀的工具支持，減輕了開發(fā)人 員肩頭的重擔(dān)。隨著 Atlas 的引入，Microsoft 對 Ajax 投入了大力支持，而名聲不太好的 Rails Web 框架也預(yù)置了充分的Ajax 支持。在 Java 世界中，Sun 已經(jīng)在其 BluePrints Solutions Catalog 中增加了許多Ajax 組件。 坦率地講，Ajax

40、 并不是什么新鮮玩藝。實際上，與這個詞相關(guān)的 “最新”術(shù)語就是 XMLHttpRequest 對象 （XHR ），它早在 IE 5 （于1999 年春天發(fā)布）中就已經(jīng)出現(xiàn)了，是作 為 Active X 控件露面的。不過，最近出現(xiàn)的新現(xiàn)象是瀏覽器的支持。原先，XHR 對象只在 IE 中得到支持（因此限制了它的使用），但是從 Mozilla 1.0 和 Safari 1.2 開始，對XHR 對象 的支持開始普及。這個很少使用的對象和相關(guān)的基本概念甚至已經(jīng)出現(xiàn)在W3C 標準中： DOM Level 3 加載和保存規(guī)約 （DOM Level 3 Load and Save Specification

41、）。現(xiàn)在，特別是 隨著 Google Maps、Google Suggest 、Gmail、Flickr 、Netflix 和 A9 等應(yīng)用變得越來越炙手可 熱，XHR 也已經(jīng)成為事實上的標準。 與前面幾頁提到的方法不同，Ajax 在大多數(shù)現(xiàn)代瀏覽器中都能使用，而且不需要任何專 門的軟件或硬件。實際上，這種方法的一大優(yōu) 就是開發(fā)人員不需要學(xué)習(xí)一種新的語言，也 不必完全丟掉他們原先掌握的服務(wù)器端技術(shù)。Ajax 是一種客戶端方法，可以與 J2EE 、.NET 、PHP 、Ruby 和 CGI 腳本交互，它并不關(guān)心服務(wù)器是什么。盡管存在一些很小 的安全限制，你還是可以現(xiàn)在就開始使用Ajax ，而且能

42、充分利用你原有的知識。 你可能會問： “誰在使用 Ajax ？”前面已經(jīng)提到，Google 顯然是最早采用 Ajax 的公司 之一，而且已經(jīng)用在很多技術(shù)上，隨便說幾個應(yīng)用，如Google Maps、Google Suggest 和 Gmail 。Yahoo!也開始引入Ajax 控件，另外Amazon 提供了一個簡潔的搜索工具，其中大量 使用了這個技術(shù)，例如，在鉆石的某一方面上移動滑塊，這會帶來動態(tài)更新的結(jié)果 （見圖1 5 ）。并不是每次改變你的查詢標準時都會更新頁面，而是在移動滑塊時就會查詢服務(wù)器， 從而更快、更容易地縮小你的選擇范圍。 圖1-5Amazon 的鉆石搜索頁面 Netflix 是

43、一家很有名的DVD 租借公司，它也使用了Ajax 。當用戶瀏覽影片時，可以得 到更詳細的信息。當顧客把鼠標放在一個影片的圖片上時，這個影片的ID 就會發(fā)送到中心 服務(wù)器，然后會出現(xiàn)一個 “氣泡”，提供這個影片的更多細節(jié) （見圖1-6）。同樣，頁面并 不會刷新，每個影片的詳細信息并不是放在隱藏的表單域中。利用這種方法，Netflix 可以提 供影片的更多信息，而不會把頁面弄亂。顧客瀏覽起來也更容易，他們不必點擊影片，看完 影片詳細信息后再點擊回到影片列表頁面；他們只需把鼠標停在影片上，就這么簡單！我們 想要強調(diào)的是，Ajax 并不限于.com之類的網(wǎng)站使用，普通公司的開發(fā)人員也開始涉足這個 技術(shù)

44、，有些人已經(jīng)在使用 Ajax 來改善原來很丑陋的驗證方案，或者用于動態(tài)地獲取數(shù)據(jù)了。 圖1-6Netflix 的瀏覽頁面特性 關(guān)鍵在于，因特網(wǎng)默認的請求/ 響應(yīng)模式有了重大轉(zhuǎn)變，這正是Ajax 的核心所在，盡管 這并非全新的內(nèi)容。Web 應(yīng) 用開發(fā)人員現(xiàn)在可以自由地與服務(wù)器異步交互，這說明他們可 以完成許多原本只能在胖客戶上完成的任務(wù)。例如，當用戶輸入郵政編碼時，可以驗證它是 否正確，然 后自動用相應(yīng)的城市名和州名填充到表單中的其他部分；或者，當用戶選擇美 國時，可以引入美國各個州的一個下拉列表。以前也可以用其他方式模擬這些工作，但 是 使用Ajax 的話，這些工作會更加簡單。 那么，是誰發(fā)明

45、了Ajax ？要找出真正的源頭，總免不了一場爭論。不過有一點是確定的， 2005 年 2 月，Adaptive Path 的Jesse James Garrett 最早創(chuàng)造了這個詞。在他的文章Ajax: A New Approach to Web Applications （Ajax ：Web 應(yīng)用的一種新方法）中，Garrett 討論了如何 消除胖客戶（或桌面）應(yīng)用與瘦客戶（或 Web ）應(yīng)用之間的界限。當然，當Google 在 Google Labs 發(fā)布 Google Maps 和 Google Suggest 時，這個技術(shù)才真正為人所認識，而且此前 已經(jīng)有許多這方面的文章了。但確實是

46、Garrett 最早提出了這個好名字，否則我們就得啰啰 嗦嗦地說上一大堆：異步 （Asynchronous ）、XMLHttpRequest 、JavaScript 、CSS、DOM 等 等。盡管原來把Ajax 認為是 Asynchronous JavaScript + XML （異步JavaScript + XML ）的縮 寫，但如今，這個詞的覆蓋面有所擴展，把允許瀏覽器與服務(wù)器通信而無需刷新當前頁面的 技術(shù)都涵蓋在內(nèi)。 你可能會說： “哦，那有什么大不了的？”這么說吧，使用XHR 而且與服務(wù)器異步通 信，就能創(chuàng)建更加動態(tài)的Web 應(yīng)用。例如，假設(shè)你有一個下拉列表，它是根據(jù)另外一個域 或下拉

47、列表的輸入來填寫的。在正常情況下，必須在加載第一個頁面時把所有數(shù)據(jù)都發(fā)送給 客戶端，然后使用 JavaScript 根據(jù)輸入來填寫下拉列表。這么做并不困難，但是會讓頁面變 得很臃腫，取決于這個下拉列表到底有多 “動態(tài)”，頁面有可能膨脹得過大，從而出現(xiàn)問題。 利用Ajax ，當作為觸發(fā)源的域有變化，或者失去了輸入焦點，就可以向服務(wù)器發(fā)一個簡單的 請求，只要求得到更新下拉列表所需的部分信息即可。 來單獨考慮一下驗證。你寫過多少次JavaScript 驗證邏輯？用 Java 或 C#編寫驗證邏輯可 能很簡單，但是由于JavaScript 缺乏很好的調(diào)試工具，再加上它是一種弱類型語言，所以用 Java

48、Script 編寫驗證邏輯實在是一件讓人頭疼的事情，而且很容易出錯。服務(wù)器上還很有可 能重復(fù)這些客戶端驗證規(guī)則。使用XHR ，可以對服務(wù)器做一個調(diào)用，觸發(fā)某一組驗證規(guī)則。 這些規(guī)則可能比你用 JavaScript 編寫的任何規(guī)則都更豐富、更復(fù)雜，而且你還能得到功能強 大的調(diào)試工具和集成開發(fā)環(huán)境 （IDE ）。 你現(xiàn)在可能又會說： “這些事情我早已經(jīng)用 IFRAME 或隱藏框架做到了。”我們甚至還 使用這種技術(shù)來提交或刷新過頁面的一部分，而不是整個瀏覽器（頁面）。不能不承認，這 確實可行。不過，許多人認為這種方法只是一種修補手段，以彌補XHR 原來缺乏對跨瀏覽 器的支持。作為 Ajax 的核心，

49、XHR 對象設(shè)計為允許從服務(wù)器異步地獲取任意的數(shù)據(jù)。 我們討論過，傳統(tǒng)的Web 應(yīng)用遵循一種請求/ 響應(yīng)模式。如果沒有Ajax ，對于每個請求 都會重新加載整個頁面（或者利用 IFRAME ，則是部分頁面）。原來查看的頁面會放到瀏覽 器的歷史棧中（不過，如果使用了 IFRAME ，點擊 “后退”按鈕不一定能得到用戶期望的歷 史頁面）。與此不同，用XHR 做出的請求不會記錄在瀏覽器的歷史中。如果你的用戶習(xí)慣 于使用 “后退”按鈕在 Web 應(yīng)用中進行導(dǎo)航，就可能會產(chǎn)生問題。 1.4 可用性問題 前面談到的都是用戶的期望，除此以外，可用性也不能不提。Ajax 方法相當新，還沒有多少 成熟的最佳實踐

50、。不過，標準Web 設(shè)計原則還是適用的。隨著時間推移，當越來越多的人 開始嘗試這種方法時，就會發(fā)現(xiàn)可能存在哪些限制，并建立適當?shù)闹笇?dǎo)原則。也就是說，你 應(yīng)該讓用戶來指導(dǎo)你。根據(jù)在應(yīng)用中使用 Ajax 的方式，你可能會動態(tài)地改變頁面中的某些 部分，習(xí)慣于整個瀏覽器刷新的用戶可能不會注意到與以前相比有什么變化。這個問題引出 了一些新的特性，如37signals 所普及的黃褪技術(shù)（Yellow Fade Technique ，YFT ），這個特 性已經(jīng)用在 Ajax 的招牌應(yīng)用 Basecamp 中了。 基本說來，YFT 是指 “取頁面中有變化的部分，并置為黃色”。假設(shè)你的應(yīng)用原本沒有 大量使用黃色

51、，用戶就很可能會注意到這種改變。過一段時間后，再讓黃色逐漸褪色，直到 恢復(fù)為原來的背景色。當然，你也可以選用你喜歡的其他顏色，只要能把用戶的注意力吸引 到有變化的部分。 可能YTF 并不適用于你的應(yīng)用，你也可以選擇用一種不那么張揚但仍很有用的方式來提 醒用戶。Gmail 在右上角顯示了一個閃動的紅色 “Loading”加載記號，提醒用戶正在獲取數(shù) 據(jù) （見圖1-7）。 圖1-7Gmail 的 “Loading”記號 究竟要使用YFT 還是其他類似的技術(shù)，實際上取決于你的用戶。最簡單的方法是讓一組 用戶代表來進行 試?？梢酝ㄟ^文字問卷，也可以使用基于Web 的原型應(yīng)用，這要看你處 在設(shè)計過程的哪

52、個階段。但是不論如何 試，在真正采用 Ajax 完成復(fù)雜設(shè)計之前都應(yīng)該取 得一些用戶反饋。 而且要從小處做起。在剛開始使用Ajax 時，不應(yīng)該馬上就創(chuàng)建一個可調(diào)整列的動態(tài)門戶 網(wǎng)站，而是應(yīng)該先試著處理客戶端驗證，逐步轉(zhuǎn)向服務(wù)器端。待有所了解后，可以再嘗試更 動態(tài)的使用，如填寫一個下拉列表，或者設(shè)置某些默認文本。 不管你要如何應(yīng)用Ajax ，記住別做稀奇古怪的事情。我們知道，這不算是一個學(xué)術(shù)性的 建議。不過，目前這方面還沒有嚴格的規(guī)則。先聽聽用戶怎么說，部署之前一定要先做 試， 而且要記住，如果太過古怪，用戶很快就會點擊 “跳過本頁”鏈接跳過你精心設(shè)計的這些部 分。 要知道使用Ajax 時有幾個

53、常犯的錯誤。我們已經(jīng)討論過，有變化時如何向用戶提供可視 化的提示，不僅如此，Ajax 還會以其他方式改變標準的 Web 方法。首先，不同于IFRAME 和隱藏框架，通過XHR 做出請求不會修改瀏覽器的歷史棧。在許多情況下這沒有什么問題 （你可能會點擊后退箭頭，只是要看看是不是什么都沒有改變，但這么做能有幾次呢？）， 不過，如果你的用戶確實想用后退按鈕，就有問題了。 其次，與其他基于瀏覽器的方法不同，Ajax 不會修改地址欄中顯示的鏈接，這表明你不 能輕松地為一個頁面建立書簽，或者向朋友發(fā)送一個鏈接。對于許多應(yīng)用來說，可能沒有這 個要求，但是如果你的網(wǎng)站專門為人提供行車路線之類的東西，就要針對這

54、個問題提供一個 解決方案。 有一點很重要，使用Ajax 不要過度。記住，JavaScript 會在客戶端的瀏覽器上運行，如 果有數(shù)千行 JavaScript 代碼，可能會讓用戶感覺速度太慢。如果腳本編寫不當，就會很快失 去控制，特別是當通信量增加時。 Ajax 允許你異步地完成操作，這個最大的優(yōu)點同時也是它最突出的缺點。我們以前總是 告訴用戶，Web 應(yīng)用是以一種請求/ 響應(yīng)模式完成操作的，用戶也已經(jīng)接受了這種思想。但 是用了Ajax ，就不再有這個限制。我們可以只修改頁面的一部分，如果用戶沒想到這一點， 他們很可能會被搞糊涂。所以，你要注意一定要讓用戶明白這一點，不要想當然地以為他們 知道。

55、記住，只要有疑問，就要請用戶代表進行 試！ 1.5 相關(guān)技術(shù) 當你看到本書時，可能已經(jīng)了解了在應(yīng)用中實現(xiàn)Ajax 所需的大多數(shù)技術(shù)。重申一句，我 們想強調(diào)的是，Ajax 是一個客戶端技術(shù)，不論你現(xiàn)在使用何種服務(wù)器端技術(shù)，都能使用 Ajax ，而不管使用的是Java 、.NET 、Ruby 、PHP 還是 CGI 。實際上，在這本書中我們并不 考慮服務(wù)器端，而且假設(shè)你已經(jīng)很清楚如何結(jié)合日常工作中使用的服務(wù)器端技術(shù)。在后面的 幾百頁中，我們強調(diào)的重點是客戶端技術(shù)和方法，創(chuàng)建豐富的基于瀏覽器的應(yīng)用時需要用到 這些技術(shù)。 盡管可以使用你喜歡的任何服務(wù)器端技術(shù)，但當使用 Ajax 時還是需要轉(zhuǎn)變一下思想

56、。在 一般的Web 應(yīng)用中，服務(wù)器端代碼會呈現(xiàn)一個完整的頁面，并涉及一個完整的工作單元。 利用Ajax ，可能只返回一點點文本，而且只涉及一個業(yè)務(wù)應(yīng)用的很小子集。對于大多數(shù)有經(jīng) 驗的Web 開發(fā)人員來說，理解起來沒有什么問題，但是一定要記住這一點。 一些新興的框架有助于開發(fā)人員跳出Ajax 的一些細節(jié)。不過，你還是要對 JavaScript 有 所了解。我們知道，JavaScript 用起來可能很費勁。但很遺憾，對此沒有什么辦法。我們大 多數(shù)人都學(xué)過這么一招，把 “alert”作為一種系統(tǒng)類型輸出來幫助調(diào)試，糟糕的是，這種技 術(shù)使用得還很廣。不過，現(xiàn)在我們有了新的利器。 除了JavaScrip

57、t ，你還要熟悉其他一些與表示相關(guān)的技術(shù)，如HTML 、DOM 和 CSS 。你 不必是這方面的專家，但是基本了解還是必要的。本書中我們會談到你需要知道的大多數(shù)內(nèi) 容，沒有談到的內(nèi)容可以參考網(wǎng)上的資源。 關(guān)于 試驅(qū)動 （你肯定寫過單元 試，對不對？），我們會介紹JsUnit 和 Selenium （見 圖1-8）。利用這些工具，可以先開發(fā)JavaScript 試，并檢查瀏覽器兼容性 試。通常認為， 下一代開發(fā)環(huán)境會對 JavaScript 提供更好的支持，另外一些與Ajax 相關(guān)的技術(shù)會進一步減輕 開發(fā)人員的負擔(dān)。正在不斷出現(xiàn)的腳本和框架也會使開發(fā)變得更為簡單。 圖1-8Selenium 1.

58、6 使用場合 既然你已經(jīng)對 Ajax 產(chǎn)生了興趣，還要知道重要的一點，即什么時候應(yīng)該使用Ajax 技術(shù)， 而什么時候不該用。首先，不要害怕在應(yīng)用中嘗試新的方法。我們相信，幾乎每個 Web 應(yīng) 用都能從 Ajax 技術(shù)中獲益，只不過不要矯枉過正，過于離譜就行了。從驗證開始就很合適， 但是不要限制你的主動性。你當然可以使用Ajax 提交數(shù)據(jù)，但也許不能把它作為提交數(shù)據(jù) 的主要方法。 其次，惟一會影響你應(yīng)用 Ajax 的就是瀏覽器問題。如果大量用戶（或者特別重要的用戶） 還在使用比較舊的瀏覽器，如IE 5 、Safari 1.2 或Mozilla 1.0 之前的版本，Ajax 技術(shù)就不能奏 效。如果

59、這是一些很重要的用戶，你就要使用針對 目標用戶的跨瀏覽器的方法，而放棄 Ajax ，或者開發(fā)一個可以妥善降級的網(wǎng)站。瀏覽器支持可能不是一個重要因素，因為 Netscape Navigator 4 在市場上的份額很小。不過，還是應(yīng)該查看Web 日志，看看你的應(yīng)用適 用什么技術(shù)。 如前所述，驗證和表單填寫就非常適合采用 Ajax 實現(xiàn)。還可以使用DOM 的 “拖”技術(shù) 建立真正動態(tài)的網(wǎng)站，如Google 的個性化主頁 （見圖1-9）。 圖1-9Google 的個性化主頁 可以看到，Ajax 為Web 應(yīng)用開發(fā)提供了新的機會。你不會再因為以往的專用技術(shù)或技 術(shù)折中方案而受到妨礙。利用Ajax ，胖客

60、戶與瘦客戶之間的界限不再分明，真正的贏家則是 你的用戶。 1.7 設(shè)計考慮 既然對在哪里使用Aj ax 已經(jīng)有所認識，下面再來談?wù)剳?yīng)用 Aj ax 的一些設(shè)計考慮。許多 原則與Web 應(yīng)用的原則并無不同，不過還是有必要強調(diào)一下。要盡力減少客戶和服務(wù)器之 間的通信量。如果應(yīng)用得當，Aj ax 會使你的應(yīng)用響應(yīng)更快，但是如果每次用戶從一個域移到 另一個域時你都來回傳遞超量的數(shù)據(jù)，用戶肯定不會滿意。如果有疑問，按標準約定行事。 如果大多數(shù)應(yīng)用都那么做，可能你也應(yīng)該那么做。如果還有問題，可以看看Web 桌面應(yīng)用 的有關(guān)標準。為此已經(jīng)建立了一些模式，而且以后還會有更多的模式 （）。 在剛開始使用Ajax