掌握 Ajax，第 8 部分: 在请求和响应中使用 XML
| Ajax 客戶機/服務器通信可以很巧妙 |
級別： 中級 Brett McLaughlin (brett@newInstance.com), 作家，編輯, O'Reilly Media Inc. 2006 年 12 月 21 日 在 本系列的上一篇文章 中，您看到了 Ajax 應用程序如何以 XML 格式化發往服務器的請求。還了解了為什么這在大多數情況下并不是一個好主意。這篇文章主要探討在大多數情況下確實是 好主意的一種做法：向客戶機返回 XML 響應。我其實并不喜歡寫那種主要告訴您什么不應該 做的文章。很多時候，那都會是一篇非常愚蠢的文章。我要在前半篇文章中解釋某些東西，然后在后半篇文章中說明使用您剛剛才學會的那種技術是一個多么糟糕的主意。在很大程度上，上一期文章正是這樣一種情況（如果您錯過了那一期文章，請查看 參考資料 中的鏈接），那篇文章教您如何將 XML 作為 Ajax 應用程序的請求數據格式使用。 但愿這篇文章能夠彌補您花費在學習 XML 請求上的時間。在 Ajax 應用程序中，使用 XML 作為發送數據的格式的理由很少，但使服務器向 客戶機回發 XML 的理由很多。因此，您在上一篇文章中學到的關于 XML 的知識最終將在這篇文章中體現出某些價值。 服務器（有時）不能響應太多的請求 在深入鉆研從服務器獲取 XML 響應的技術之前，您需要理解，為什么說使服務器發送 XML 來響應請求是一個好主意（以及這與客戶機發送 XML 請求不同的原因所在）。 客戶機以名稱/值對發送請求 回憶一下上一篇文章，就會知道，在大多數情況下，客戶機不需要使用 XML，因為他們會使用名稱/值對發送請求。因此，您可能會發送一個這樣的名稱：name=jennifer。只需簡單地在連續的名稱/值對之間添加一個 “與” 符號（&），即可將其放在一起，就像這樣：name=jennifer&job=president。使用簡單的文本和這些名稱值對，客戶機即可輕松向服務器請求多個值。很少需要用到 XML 提供的額外結構（及其帶來的額外開銷）。 實際上，需要向服務器發送 XML 的所有理由都差不多可以歸入以下兩個基本的類別中：
服務器無法（以一種標準方式）發送名稱/值對 在您發送名稱/值對時，Web 瀏覽器會發送請求，平臺會響應該請求，并承載一個服務器程序，配合它將那些名稱/值對轉換成服務器程序可以輕松處理的數據。實際上，每一種服務器端技術 —— 從 Java? servlet 到 PHP、再到 Perl、Ruby on Rails —— 都允許您調用多種方法來根據名稱獲取值。因此，獲取 name 屬性只是小事一樁。 這種情況并不會將我們引向另外一個方向。如果服務器使用字符串 name=jennifer&job=president 應答一個應用程序，客戶機沒有任何標準化的簡便方法來將每個對拆分成名稱和值。您必須手動解析所返回的數據。如果服務器返回一個由名稱/值對構成的響應，這樣的響應的解釋難度與使用分號、豎線或其他任何非標準格式化字符相同。
對于您來說，這就意味沒有任何簡單的方法在響應中使用純文本、使客戶機以一種標準的方法獲取并解釋響應，至少在響應包含多個值時是如此。假設您的服務器只是要發回數字 42，那么純文本是很好的選擇。但如果服務器要一次性發回電視劇 Lost, Alias 和 Six Degrees 的近期收視率又該怎么辦呢？盡管可以選擇許多種方法來使用純文本發送這一響應（清單 1 給出了一些示例），但沒有一種是不需客戶機進行某些處理的極其簡單的方法，也沒有一種是標準化的方法。 清單 1. 收視率的服務器響應（不同版本）
盡管不難找到拆分這些響應字符串的方法，但客戶機將不得不根據分號、等號、豎線和與符號解析并拆分這些字符串。這不是編寫使其他開發人員能夠輕松理解和維護的健壯代碼的方法。 進入 XML 意識到沒有任何標準的方法可以使服務器使用名稱/值對響應客戶機之后，使用 XML 的原因也就顯而易見了。向客戶機發送數據時，名稱/值對是非常好的選擇，因為服務器和服務器端語言可以輕松解釋名稱/值對；向客戶機返回數據時使用 XML 也是如此。在本系列前幾期的文章中，您已經看到了利用 DOM 來解析 XML，在后續的文章中，還會看到 JSON 怎樣提供了解析 XML 的另一種選擇。在所有這一切之上，您可以將 XML 作為純文本處理，并以這種方式獲取其值。因此，有幾種方法可從服務器獲得 XML 響應，并使用較為標準的代碼提取數據，在客戶機中使用這些數據。 還有一個額外的好處，XML 非常易于理解。比如說，大多數編寫程序的人都能理解 清單 2 中的數據。 清單 2. 收視率的服務器響應（XML 格式）
在特定分號或撇號的含義方面，清單 2 中的代碼沒有任何隱晦之處。
從服務器接收 XML 由于本系列的重點在于 Ajax 應用模式的客戶端，因此我不會深入探討關于服務器端程序如何才能生成 XML 響應的細枝末節。但在您的客戶機接收 XML 時，您需要了解一些特殊的考慮事項。 首先，您可使用兩種基本的方式處理一個來自服務器的 XML 響應：
其次，舉例來說，假設有一個來自服務器的簡單 XML 響應。清單 3 展示了與上面介紹的內容相同的收視率程序清單（實際上，是與 清單 2 相同的 XML，在這里再次給出只是為了使您便于查看）。我將在這部分的討論中使用這段樣本 XML。 清單 3. XML 格式的收視率示例
將 XML 作為純文本處理 處理 XML 的最簡單的選擇（至少就學習新的編程技術而言），就是用與處理服務器返回的其他文本片段相同的方法來處理它。換言之，基本上就是忽略數據格式，只關注服務器的響應。 在這種情況下，您要使用請求對象的 responseText 屬性，就像在服務器向您發送非 XML 響應時一樣（參見 清單 4）。 清單 4. 將 XML 作為普通服務器響應處理
在這個代碼片段中，updatePage() 是回調方法，request 是 XMLHttpRequest 對象。最終，您將得到把所有一切串聯在一起的 XML 響應，位于 response 變量之中。如果輸出此變量，您會得到類似于清單 5 的結果。（請注意，清單 5 中的代碼在正常情況下應該是連續的一個代碼行。這里采用多行形式是為了顯示正常。） 清單 5. response 變量的值
這里，要注意的最重要的地方就是 XML 是作為整體運行的。在大多數情況下，服務器不會使用空格和回車來格式化 XML，而是將一切串聯在一起，就像您在 清單 5 中看到的那樣。當然，您的應用程序不會過于在意空格，所以這算不上什么問題，但確實會使代碼閱讀起來較為困難。 在這里，您可以使用 JavaScript split 函數來拆分此數據，并通過基本的字符串操作來獲得元素的名稱和值。毫無疑問，這是個令人頭疼的過程，它無視于您花費了大量時間來閱讀前幾期文章中 DOM（Document Object Model）相關內容這一事實。因此，我要強調，您應該牢記：利用 responseText，可以輕松使用和輸出服務器的 XML 響應，但我不會為您展示太多的代碼，在能夠使用 DOM 時，您不應選擇這種方法來獲得 XML 數據，下面您會看到這一點。 將 XML 當成 XML 盡管可以 將服務器的 XML 格式的響應視同為其他任何文本響應來處理，但這樣做沒有很好的理由。首先，如果您一直忠實地閱讀這個系列，那么您已經學會了如何使用 DOM 這種對 JavaScript 友好的 API 來操縱 XML。還有更好的事情，JavaScript 和 XMLHttpRequest 對象提供了一個屬性，它能完美地獲取服務器的 XML 響應，并且是以 DOM Document 對象的形式來獲取它。 清單 6 給出了一個實例。這段代碼與 清單 4 類似，但沒有使用 responseText 屬性，回調函數使用的是 responseXML 屬性。該屬性在 XMLHttpRequest 上可用，它以 DOM 文檔的格式返回服務器的響應。 清單 6. 將 XML 當作 XML
現在您有了一個 DOM Document，可以像處理其他任何 XML 一樣處理它。例如，隨后可能要獲取所有 show 元素，如 清單 7 所示。 清單 7. 獲取所有 show 元素
如果您熟悉 DOM，從這兒開始，看起來就應該有幾分熟悉了。您可以使用您所了解的全部 DOM 方法，輕松操縱從服務器處接收到的 XML。 當然，您也可以混用普通的 JavaScript 代碼。例如，可以遍歷所有 show 元素，如 清單 8 所示。 清單 8. 遍歷所有 show 元素
通過這段非常簡單的代碼，您正是將 XML 響應作為 XML 而不是無格式的純文本進行了處理，還使用了一點 DOM 和簡單的 JavaScript 來處理服務器響應。更重要的是，您使用了標準化的格式 —— XML，而不是以逗號分隔的值或以豎線分隔的名稱/值對。換句話說，您將 XML 用在了最適合它的地方，避免了在不適合的地方使用它（比如說向服務器發送請求時）。 服務器端的 XML：一個簡單的示例 我不會談太多有關如何在服務器上生成 XML 的內容，但花點兒時間看一個簡單的示例是值得的，我沒有給出過多的注釋，以便您自行思考如何應對這樣的場景。清單 9 展示了一個簡單的 PHP 腳本，假設有一個異步客戶機發出了請求，該腳本將輸出 XML 來應答此請求。 這是一種強力（brute force）的方法，PHP 腳本實際上是手動生成 XML 輸出。您可以找到許多工具包和 API，用于 PHP 和其他眾多允許您生成 XML 響應的服務器端語言。無論您的情況如何，這都至少能讓您了解生成 XML 并以之應答請求的服務器端腳本看上去是什么樣子。 清單 9. 返回 XML 的 PHP 腳本
您應能夠使用您偏愛的服務器端語言以類似的方式輸出 XML。IBM developerWorks 上有許多文章可以幫助您了解如何使用您喜愛的服務器端語言生成 XML 文檔（相關鏈接請參見 參考資料）。
解釋 XML 的其他可選方法 除將 XML 作為無格式文本處理或使用 DOM 處理之外，還有一種非常流行的選擇很重要，值得一提。那就是 JSON（JavaScript Object Notation），這是一種綁定在 JavaScript 內的自由文本格式。這篇文章中沒有足夠的空間介紹 JSON，在后續文章中將探討相關內容；只要提起 XML 和 Ajax 應用程序，您就很可能會聽到有人談論 JSON，因此現在我將告訴您，您的工作伙伴們在談論的究竟是什么。 大體上，可以用 JSON 做的事，用 DOM 都可以完成，反之亦然；選擇主要取決于偏好，當然也要為特定的應用程序選擇正確的方法。就現在而言，您應堅持使用 DOM，在接收服務器響應的過程中熟悉 DOM。我將占用幾期文章的篇幅、用大量的時間去探討 JSON，之后您就可以隨意選擇在下一個應用程序中使用那種技術了。請繼續關注本系列：后續文章中將介紹關于 XML 的更多內容。
結束語 從本系列上一篇文章開篇起，我幾乎一直在談論 XML，但對于 XML 在 Ajax 應用模式中的貢獻而言，我觸及的依然僅僅是表面。在下一期文章中，您將更詳細地了解那些您將希望 發送 XML 的特殊場景（還會看到那些需要接收 XML 的場景）。具體來說，您會在 Ajax 交互的角度上觀察 Web 服務 —— 包括專有 Web 服務和 Google 那樣的 API。 簡而言之，最重要的任務就是思考對于您的應用程序，XML 在什么時候才是有意義的。在很多情況下，如果您的應用程序工作良好，XML 只不過是又一個讓您頭疼的技術時髦詞匯，您應該克制住僅僅為了宣稱應用程序中有 XML 而嘗試它的沖動。 如果您處于這樣一個環境中：服務器向您發送的數據非常有限，或者采用的是奇怪的逗號分隔、豎線分隔的格式，那么 XML 可能會給您帶來真正的收益?？紤]處理或更改您的服務器端組件，以使它們用更為標準化的方式 —— 使用 XML —— 來返回響應，而不是使用那些健壯性比 XML 差的專用格式。 最重要的是，要認識到，您對 Ajax 相關技術了解的越多，就必須越謹慎地制定決策。編寫那些 Web 2.0 應用程序確實很有趣（在后續文章中，您將重返用戶界面，看看可以在這里做些什么很酷的東西），但要注意，確保您不是為了向朋友炫耀而在一個可以正常工作的 Web 頁面上濫用這些技術。我確信，您能編寫出優秀的應用程序，那么就動手去做吧。完成后，再回來閱讀下一期文章，學習關于 XML 的更多知識。 參考資料 學習
|
轉載于:https://www.cnblogs.com/China-Dragon/archive/2010/05/07/1730143.html
總結
以上是生活随笔為你收集整理的掌握 Ajax，第 8 部分: 在请求和响应中使用 XML的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： ref
- 下一篇： asp.net ajax控件工具集 Au