AJAX核心對象– XMLHttpRequest 對象使用詳解 (二)

　　 挑戰非同步性

　　本文的後面，我將用很多時間編寫和使用非同步代碼，但是您應該明白為什麼 open() 的最後一個參數這麼重要。在一般的請求/響應模型中，比如 Web 1.0，客戶機（瀏覽器或者本地機器上啟動並執行代碼）向伺服器發出請求。該請求是同步的，換句話說，客戶機等待伺服器的響應。當客戶機等待的時候，至少會用某種形式通知您在等待：

　　·沙漏（特別是 Windows 上）。

　　·旋轉的皮球（通常在 Mac 機器上）。

　　·應用程式基底本上凍結了，然後過一段時間游標變化了。

　　這正是 Web 應用程式讓人感到笨拙或緩慢的原因 —— 缺乏真正的互動性。按下按鈕時，應用程式實際上變得不能使用，直到剛剛觸發的請求得到響應。如果請求需要大量伺服器處理，那麼等待的時間可能很長（至少在這個多處理器、DSL 沒有等待的世界中是如此）。

　　而非同步請求不 等待伺服器響應。發送請求後應用程式繼續運行。使用者仍然可以在 Web 表單中輸入資料，甚至離開表單。沒有旋轉的皮球或者沙漏，應用程式也沒有明顯的凍結。伺服器悄悄地響應請求，完成後告訴原來的要求者工作已經結束（具體的辦法很快就會看到）。結果是，應用程式感覺不 那麼遲鈍或者緩慢，而是響應迅速、互動性強，感覺快多了。這僅僅是 Web 2.0 的一部分，但它是很重要的一部分。所有老套的 GUI 組件和 Web 設計範型都不能克服緩慢、同步的請求/響應模型。

　　發送請求

　　一旦用 open() 配置好之後，就可以發送請求了。幸運的是，發送請求的方法的名稱要比 open() 適當，它就是 send()。

　　send() 只有一個參數，就是要發送的內容。但是在考慮這個方法之前，回想一下前面已經通過 URL 本身發送過資料了：

var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone);

　　雖然可以使用 send() 發送資料，但也能通過 URL 本身發送資料。事實上，GET 請求（在典型的 Ajax 應用中大約佔 80%）中，用 URL 發送資料要容易得多。如果需要發送安全資訊或 XML，可能要考慮使用 send() 發送內容。如果不需要通過 send() 傳遞資料，則只要傳遞 null 作為該方法的參數即可。因此您會發現在本文中的例子中只需要這樣發送請求（參見 清單 10）。

　　清單 10. 發送請求

function getCustomerInfo() { 　var phone = document.getElementById("phone").value; 　var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone); 　request.open("GET", url, true); 　request.send(null); }

指定回調方法

　　現在我們所做的只有很少一點是新的、革命性的或非同步。必須承認，open() 方法中 “true” 這個小小的關鍵字建立了非同步請求。但是除此之外，這些代碼與用 Java servlet 及 JSP、PHP 或 Perl 編程沒有什麼兩樣。那麼 Ajax 和 Web 2.0 最大的秘密是什麼呢？秘密就在於 XMLHttpRequest 的一個簡單屬性 onreadystatechange。

　　首先一定要理解這些代碼中的流程（如果需要請回顧 清單 10）。建立其請求然後發出請求。此外，因為是非同步請求，所以 JavaScript 方法（例子中的 getCustomerInfo()）不會等待伺服器。因此代碼將繼續執行，就是說，將退出該方法而把控制返回給表單。使用者可以繼續輸入資訊，應用程式不會等待伺服器。

　　這就提出了一個有趣的問題：伺服器完成了請求之後會發生什嗎？答案是什麼也不發生，至少對現在的代碼而言如此！顯然這樣不行，因此伺服器在完成通過 XMLHttpRequest 發送給它的請求處理之後需要某種指示說明怎麼做。

　　現在 onreadystatechange 屬性該登場了。該屬性允許指定一個回呼函數。回調允許伺服器（猜得到嗎？）反向調用 Web 頁面中的代碼。它也給了伺服器一定程度的控制權，當伺服器完成請求之後，會查看 XMLHttpRequest 對象，特別是 onreadystatechange 屬性。然後調用該屬性指定的任何方法。之所以稱為回調是因為伺服器向網頁發起調用，無論網頁本身在做什麼。比方說，可能在使用者坐在椅子上手沒有碰鍵盤的時候調用該方法，但是也可能在使用者輸入、移動滑鼠、滾動螢幕或者點擊按鈕時調用該方法。它並不關心使用者在做什麼。 這就是稱之為非同步原因：使用者在一層上動作表單，而在另一層上伺服器響應請求並觸發 onreadystatechange 屬性指定的回調方法。因此需要像 清單 11 一樣在代碼中指定該方法。

　　在 JavaScript 中引用函數

　　JavaScript 是一種弱類型的語言，可以用變數引用任何東西。因此如果聲明了一個函數 updatePage()，JavaScript 也將該函數名看作是一個變數。換句話說，可用變數名 updatePage 在代碼中引用函數。

　　清單 11. 設定回調方法

function getCustomerInfo() { 　var phone = document.getElementById("phone").value; 　var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone); 　request.open("GET", url, true); 　request.onreadystatechange = updatePage; 　request.send(null); }

　　需要特別注意的是該屬性在代碼中設定的位置 —— 它是在調用 send() 之前 設定的。發送請求之前必須設定該屬性，這樣伺服器在回答完成請求之後才能查看該屬性。現在剩下的就只有編寫 updatePage() 方法了，這是本文最後一節要討論的重點。

　　處理伺服器響應

　　發送請求，使用者高興地使用 Web 表單（同時伺服器在處理請求），而現在伺服器完成了請求處理。伺服器查看 onreadystatechange 屬性確定要調用的方法。除此以外，可以將您的應用程式看作其他應用程式一樣，無論是否非同步。換句話說，不一定要採取特殊的動作編寫響應伺服器的方法，只需要改變表單，讓使用者訪問另一個 URL 或者做響應伺服器需要的任何事情。這一節我們重點討論對伺服器的響應和一種典型的動作 —— 即時改變使用者看到的表單中的一部分。

　　回調和 Ajax

　　現在我們已經看到如何告訴伺服器完成後應該做什麼：將 XMLHttpRequest 對象的 onreadystatechange 屬性設定為要啟動並執行函數名。這樣，當伺服器處理完請求後就會自動調用該函數。也不需要擔心該函數的任何參數。我們從一個簡單的方法開始，如 清單 12 所示。

　　清單 12. 回調方法的代碼

＜script language="javascript" type="text/javascript"＞ var request = false; try { 　request = new XMLHttpRequest(); } catch (trymicrosoft) { 　try { 　　request = new ActiveXObject("Msxml2.XMLHTTP"); 　} catch (othermicrosoft) { 　　try { 　　　request = new ActiveXObject("Microsoft.XMLHTTP"); 　　} catch (failed) { 　　　request = false; 　　} 　} } if (!request) alert("Error initializing XMLHttpRequest!"); function getCustomerInfo() { 　var phone = document.getElementById("phone").value; 　var url = "/cgi-local/lookupCustomer.php?phone=" + escape(phone); 　request.open("GET", url, true); 　request.onreadystatechange = updatePage; 　request.send(null); } function updatePage() { 　alert("Server is done!"); } ＜/script＞

　　它僅僅發出一些簡單的警告，告訴您伺服器什麼時候完成了任務。在自己的網頁中實驗這些代碼，然後在瀏覽器中開啟（如果希望查看該例中的 XHTML，請參閱 清單 8）。輸入電話號碼然後離開該欄位，將看到一個彈出的警告視窗（如 圖 3 所示），但是點擊 OK 又出現了……

圖 3. 彈出警告的 Ajax 代碼

　　根據瀏覽器的不同，在表單停止彈出警告之前會看到兩次、三次甚至四次警告。這是怎麼回事呢？原來我們還沒有考慮 HTTP 就緒狀態，這是請求/響應迴圈中的一個重要部分。

HTTP 就緒狀態

　　前面提到，伺服器在完成請求之後會在 XMLHttpRequest 的 onreadystatechange 屬性中尋找要調用的方法。這是真的，但還不完整。事實上，每當 HTTP 就緒狀態改變時它都會調用該方法。這意味著什麼呢？首先必須理解 HTTP 就緒狀態。

　　HTTP 就緒狀態表示請求的狀態或情形。它用於確定該請求是否已經開始、是否得到了響應或者請求/響應模型是否已經完成。它還可以協助確定讀取伺服器提供的響應文本或資料是否安全。在 Ajax 應用程式中需要瞭解五種就緒狀態：

　　0：請求沒有發出（在調用 open() 之前）。

　　1：請求已經建立但還沒有發出（調用 send() 之前）。

　　2：請求已經發出正在處理之中（這裡通常可以從響應得到內容標題部）。

　　3：請求已經處理，響應中通常有部分資料可用，但是伺服器還沒有完成響應。

　　4：響應已完成，可以訪問伺服器響應並使用它。

　　與大多數跨瀏覽器問題一樣，這些就緒狀態的使用也不盡一致。您也許期望任務就緒狀態從 0 到 1、2、3 再到 4，但實際上很少是這種情況。一些瀏覽器從不報告 0 或 1 而直接從 2 開始，然後是 3 和 4。其他瀏覽器則報告所有的狀態。還有一些則多次報告就緒狀態 1。在上一節中看到，伺服器多次調用 updatePage()，每次調用都會彈出警告框 —— 可能和預期的不同！

　　對於 Ajax 編程，需要直接處理的惟一狀態就是就緒狀態 4，它表示伺服器響應已經完成，可以安全地使用響應資料了。基於此，回調方法中的第一行應該如 清單 13 所示。

　　 清單 13. 檢查就緒狀態

function updatePage() { 　if (request.readyState == 4) 　　alert("Server is done!"); }

　　修改後就可以保證伺服器的處理已經完成。嘗試運行新版本的 Ajax 代碼，現在就會看到與預期的一樣，只顯示一次警告資訊了。

　　HTTP 狀態代碼

　　雖然 清單 13 中的代碼看起來似乎不錯，但是還有一個問題 —— 如果伺服器響應請求並完成了處理但是報告了一個錯誤怎麼辦？要知道，伺服器端代碼應該明白它是由 Ajax、JSP、普通 HTML 表單或其他類型的代碼調用的，但只能使用傳統的 Web 專用方法報告資訊。而在 Web 世界中，HTTP 代碼可以處理請求中可能發生的各種問題。

　　比方說，您肯定遇到過輸入了錯誤的 URL 請求而得到 404 錯誤碼的情形，它表示該頁面不存在。這僅僅是 HTTP 要求能夠收到的眾多錯誤碼中的一種（完整的狀態代碼列表請參閱 參考資料 中的連結）。表示所訪問資料受到保護或者禁止訪問的 403 和 401 也很常見。無論哪種情況，這些錯誤碼都是從完成的響應 得到的。換句話說，伺服器履行了請求（即 HTTP 就緒狀態是 4）但是沒有返回客戶機預期的資料。

　　因此除了就緒狀態外，還需要檢查 HTTP 狀態。我們期望的狀態代碼是 200，它表示一切順利。如果就緒狀態是 4 而且狀態代碼是 200，就可以處理伺服器的資料了，而且這些資料應該就是要求的資料（而不是錯誤或者其他有問題的資訊）。因此還要在回調方法中增加狀態檢查，如 清單 14 所示。

　　清單 14. 檢查 HTTP 狀態代碼

function updatePage() { 　if (request.readyState == 4) 　    if (request.status == 200) 　　    alert("Server is done!"); }

　　為了增加更健壯的錯誤處理並盡量避免過於複雜，可以增加一兩個狀態代碼檢查，請看一看 清單 15 中修改後的 updatePage() 版本。

　　清單 15. 增加一點錯誤檢查

function updatePage() { 　if (request.readyState == 4) 　　if (request.status == 200) 　　　alert("Server is done!"); 　　else if (request.status == 404) 　　　alert("Request URL does not exist"); 　　else 　　　alert("Error: status code is " + request.status); }

　　現在將 getCustomerInfo() 中的 URL 改為不存在的 URL 看看會發生什麼。應該會看到警告資訊說明要求的 URL 不存在 —— 好極了！很難處理所有的錯誤條件，但是這一小小的改變能夠涵蓋典型 Web 應用程式中 80% 的問題。

　　讀取響應文本

　　現在可以確保請求已經處理完成（通過就緒狀態），伺服器給出了正常的響應（通過狀態代碼），最後我們可以處理伺服器返回的資料了。返回的資料儲存在 XMLHttpRequest 對象的 responseText 屬性中。

　　關於 responseText 中的常值內容，比如格式和長度，有意保持含糊。這樣伺服器就可以將文本設定成任何內容。比方說，一種指令碼可能返回逗號分隔的值，另一種則使用管道符（即 | 字元）分隔的值，還有一種則返回長文本字串。何去何從由伺服器決定。

　　在本文使用的例子中，伺服器返回客戶的上一個訂單和客戶地址，中間用管道符分開。然後使用訂單和地址設定表單中的元素值，清單 16 給出了更新顯示內容的代碼。

　　清單 16. 處理伺服器響應

function updatePage() { 　if (request.readyState == 4) { 　　if (request.status == 200) { 　　　var response = request.responseText.split("|"); 　　　document.getElementById("order").value = response[0]; 　　　document.getElementById("address").innerHTML = response[1].replace(/\n/g, ""); 　　} else 　　　alert("status is " + request.status); 　} }

　　首先，得到 responseText 並使用 JavaScript split() 方法從管道符分開。得到的數組放到 response 中。數組中的第一個值 —— 上一個訂單 —— 用 response[0] 訪問，被設定為 ID 為 “order” 的欄位的值。第二個值 response[1]，即客戶地址，則需要更多一點處理。因為地址中的行用一般的行分隔字元（“\n”字元）分隔，代碼中需要用 XHTML 風格的行分隔字元 ＜br /＞ 來代替。替換過程使用 replace() 函數和Regex完成。最後，修改後的文本作為 HTML 表單 div 中的內部 HTML。結果就是表單突然用客戶資訊更新了， 4 所示。

圖 4. 收到客戶資料後的 Break Neck 表單

　　結束本文之前，我還要介紹 XMLHttpRequest 的另一個重要屬性 responseXML。如果伺服器選擇使用 XML 響應則該屬性包含（也許您已經猜到）XML 響應。處理 XML 響應和處理普通文本有很大不同，涉及到解析、文件物件模型（DOM）和其他一些問題。後面的文章中將進一步介紹 XML。但是因為 responseXML 通常和 responseText 一起討論，這裡有必要提一提。對於很多簡單的 Ajax 應用程式 responseText 就夠了，但是您很快就會看到通過 Ajax 應用程式也能很好地處理 XML。

　　結束語

　　您可能對 XMLHttpRequest 感到有點厭倦了，我很少看到一整篇文章討論一個對象，特別是這種簡單的對象。但是您將在使用 Ajax 編寫的每個頁面和應用程式中反覆使用該對象。坦白地說，關於 XMLHttpRequest 還真有一些可說的內容。