| 2007 年 4 月 20 日 通過理解錯誤的編碼方式，可以更好地了解如何正確地進行編碼。當然，編寫 Asynchronous JavaScript? + XML（Ajax）有正確的方法，也有錯誤的方法。本文將討論一些需要避免的常見編碼實踐。 如果人們在第一次就能夠將所有事情全部做對，那么這個世界將變得完全不同。Ajax 也是如此。我做了大量的工作以支持 Ajax 開發(fā)人員（包括我自己），包括編碼、撰寫文章和演講。通過這些工作，我學到了很多關于正確和錯誤編寫 Ajax 的知識。在我的上一篇文章 “五種常見 Ajax 模式：可立即使用這些非常有用的 Ajax 設計模式” 中，我介紹了五種用于正確編寫 Ajax 應用程序的模式。在這篇文章中，我將介紹 Ajax 代碼中常見的五種反模式。 您可能會問，什么是反模式（anti-pattern）？反模式 就是頻繁出現的應用程序設計缺陷，已經成為所有人都應該注意的問題。我在這里將從較高的層次進行討論，而不涉及語法錯誤和鏈接問題。 大多數開發(fā)人員聽說過關于反模式的一個很好的例子：結構化查詢語言（Structured Query Language，SQL）的錯誤使用導致 Web 站點受到 SQL 注入攻擊。這種反模式使得公司損失慘重，并暴露了客戶記錄，而且不幸的是沒有一種編程語言可以幸免。因此，我們有必要了解這種模式發(fā)生的原理和原因，以及如何避免。 Ajax 反模式也是如此。我并不是說它們將造成公司損失數十億的收入，但是它們可以搞垮服務器或者提供糟糕的用戶體驗，這種代價不僅昂貴，而且令人沮喪。 如果理解了發(fā)生錯誤的內容，您將學到很多知識。很多時候，人們僅僅把 Ajax 看作是一種在加載頁面后從服務器取回 XML 的方式。這種觀點非常狹隘，并且如果被錯誤使用，將引發(fā)應用程序的性能問題。在本文中，我將解釋這種觀點之所以錯誤的原因，以及如何修復這種錯誤。 在沒有必要的時候輪詢計時器 我見到的很多 Ajax 問題都和濫用 JavaScript 語言內置的計時器功能有關。其中的關鍵方法是 window.setInterval()。只要看到這種方法，就需要稍微提高警惕；為什么要使用一個計時器呢？當然，計時器有其用途 —— 比如，動畫。 window.setInterval() 方法告訴頁面以特定的時間間隔回調某個函數（比如每秒）。大多數瀏覽器對使用這些計時器總是說得多，做得少，主要是因為 JavaScript 語言是單線程的語言。如果您要求的時間間隔為 1 秒，那么獲得的回調時間間隔可能是 1 秒、1.2 秒、9 秒或任何其他時間。
絕對不需要使用計時器的一種情況就是等待 Ajax 請求的完成。以 清單 1 為例。
清單 1. Antipat1a_polling.html
<html><script> var req = null; function loadUrl( url ) { if(window.XMLHttpRequest) { try { req = new XMLHttpRequest(); } catch(e) { req = false; } } else if(window.ActiveXObject) { try { req = new ActiveXObject(‘Msxml2.XMLHTTP‘); } catch(e) { try { req = new ActiveXObject(‘Microsoft.XMLHTTP‘); } catch(e) { req = false; } } } if(req) { req.open(‘GET‘, url, true); req.send(‘‘); } } window.setInterval( function watchReq() { if ( req != null && req.readyState == 4 && req.status == 200 ) { var dobj = document.getElementById( ‘htmlDiv‘ ); dobj.innerHTML = req.responseText; req = null; } }, 1000 ); var url = window.location.toString(); url = url.replace( /antipat1a_polling.html/, ‘antipat1_content.html‘ ); loadUrl( url ); </script><body> Dynamic content is shown between here:<br/> <div id="htmlDiv" style="border:1px solid black;padding:10px;"> </div>And here.</body></html> |
在進行 setInterval 調用之前，所有一切看上去都工作得不錯。這個調用將設置監(jiān)視請求狀態(tài)的計時器，然后使用下載的資源設置頁面內容。 我將展示一個更好的解決方案，用來計算出什么時候請求能夠完成。同時，清單 2 展示了頁面正在請求的文件。
清單 2. Antipat1_content.html
同時 圖 1 顯示了在我的瀏覽器中看到的頁面。
圖 1. 放置在 HTML 文檔中的內容
所以，您可能會問自己，“它現在可以工作，不是嗎？如果沒有出現故障的話，為什么要修復呢？” 實際上已經出現故障了，因為程序運行得非常慢。計時器將時間間隔設置為 1 秒，隨著時間的流逝，請求完全超過了時間間隔。所以，您將看到頁面首先出現一個空的框，然后再等待一秒鐘，忽然出現大量的內容。多么糟糕！ 如何解決呢？Ajax 天生就是異步的。難道不需要進行輪詢循環(huán)就能查看何時完成請求嗎？ 結果證明，并非如此。正如我在 清單 3 中展示的一樣，XMLHTTPRequest 對象所提供的全部內容是一個名為 onreadystatechange 的回調機制。（多么好聽的名字，讓人想起了 VAX PDP/11s）。
清單 3. Antipat1a_fixed.html
<html><script> var req = null; function processReqChange() { if (req.readyState == 4 && req.status == 200 ) { var dobj = document.getElementById( ‘htmlDiv‘ ); dobj.innerHTML = req.responseText; } } function loadUrl( url ) { ... if(req) { req.onreadystatechange = processReqChange; req.open(‘GET‘, url, true); req.send(‘‘); } } var url = window.location.toString(); url = url.replace( /antipat1a_fixed.html/, ‘antipat1_content.html‘ ); loadUrl( url ); </script> ... |
這個新代碼只是查看請求對象是否發(fā)生改變，以響應 onreadystatechange 回調。然后，在完成后更新頁面。 最后的結果是一個加載神速的頁面。頁面出現后，新的內容幾乎是立即填充了頁面框。為什么呢？因為請求完成后就立即調用了代碼，然后填充頁面。沒有必要將時間浪費在無聊的計時器上。 輪詢反模式的另一個變體是：頁面反復向服務器發(fā)送請求，即使請求沒有發(fā)生變化。請看 清單 4 所示的搜索頁面。
清單 4. Antipat1b_polling.html
<html><script> var req = null; function processReqChange() { if (req.readyState == 4 && req.status == 200 ) { var dobj = document.getElementById( ‘htmlDiv‘ ); dobj.innerHTML = req.responseText; } } function loadUrl( url ) { ... } window.setInterval( function watchSearch() { var url = window.location.toString(); var searchUrl = ‘antipat1_content.html?s=‘+searchText.value; url = url.replace( /antipat1b_polling.html/, searchUrl ); loadUrl( url ); }, 1000 ); </script><body><form> Search <input id="searchText" type="text">:<br/> <div id="htmlDiv" style="border:1px solid black;padding:10px;"> </div></form></body></html> |
您可以看到瀏覽器中的頁面能夠發(fā)揮作用，如 圖 2 所示。
圖 2. 具有動態(tài)響應區(qū)域的搜索區(qū)域
多么美妙。這樣看來，頁面非常合理。當我改變搜索文本時，顯示結果的區(qū)域也將根據新的搜索條件改變（也許并不完全如此，但是如果為請求安裝一個真正的搜索引擎，它就會這樣做）。 問題是 JavaScript 代碼使用 window.setInterval 來不斷地生成請求，即使搜索字段沒有發(fā)生更改。這將消耗網絡帶寬，并消耗服務器時間。對于一個流行的站點來說，這可是一個致命的組合。 解決方法就是對搜索框使用事件回調，如 清單 5 所示。
清單 5. Antipat1b_fixed.html
<html><script> var req = null; function processReqChange() { ... } function loadUrl( url ) { ... } var seachTimer = null; function runSearch() { if ( seachTimer != null ) window.clearTimeout( seachTimer ); seachTimer = window.setTimeout( function watchSearch() { var url = window.location.toString(); var searchUrl = ‘antipat1_content.html?s=‘+searchText.value; url = url.replace( /antipat1b_fixed.html/, searchUrl ); loadUrl( url ); seachTimer = null; }, 1000 ); } </script><body><form> Search <input id="searchText" type="text" onkeyup="runSearch()">:<br/> <div id="htmlDiv" style="border:1px solid black;padding:10px;"> </div></form></body></html> |
這里，我將 runSearch() 函數與搜索框的 onkeyup() 方法關聯(lián)起來。通過這樣做，當用戶在搜索框中輸入內容時，我將得到回調。 runSearch() 函數執(zhí)行得非常漂亮。它為調用服務器并實際運行搜索的另一個方法設置了一個超時。如果在設置之前還沒有超時，那么將清除該超時。為什么？因為這將允許用戶輸入大量的文本；然后，當用戶按下最后一個鍵時，第二種方法將運行搜索。通過這種方法，用戶將不再被不斷閃爍的顯示打擾。
沒有檢查回調返回的結果 許多 Ajax 反模式源于對 XMLHTTPRequest 對象機制的誤解。我經?？吹降囊环N情況就是，用戶沒有在回調中檢查對象的 readyState 或 status 字段。請查看 清單 6 以理解我所說的含義。
清單 6. Antipat2_nocheck.html
<html><script> var req = null; function processReqChange() { var dobj = document.getElementById( ‘htmlDiv‘ ); dobj.innerHTML = req.responseText; } ... </code> <p>Everything looks okay. And on small requests, and on some browsers, it‘s probably fine. But many requests are large enough to call several calls to the <code type="inline">onreadystatechange</code> handler before they finish. So, your callback might be working with incomplete data.</p> <p>The right way to do it is shown in <a href="#list7">Listing 7</a>.</p> <code type="section"> <heading refname="list7" type="code">Listing 7. Antipat2_fixed.html</heading> <html><script> var req = null; function processReqChange() { if (req.readyState == 4 && req.status == 200 ) { var dobj = document.getElementById( ‘htmlDiv‘ ); dobj.innerHTML = req.responseText; } } ... |
沒有太多的代碼，并且它可以在所有瀏覽器上工作。 我注意到，和其他瀏覽器相比，這個問題在 Windows? Internet Explorer? 7 上尤為突出。Internet Explorer 7 對 onreadystatechange 進行多次回調 —— 我的意思是說即使對小的請求也多次進行回調。因此，需要正確編寫處理程序。
在使用 HTML 更合適的時候卻傳送復雜的 XML 在我工作的一家公司中，所有的談論都是關于 “在網絡的邊緣實現智能化”。關于這個簡單思想的另一個比較有趣的說法就是：通過在桌面上實現瀏覽器的智能化工作來替代服務器中的全面處理。 但是在頁面中實現智能化意味著在其中使用大量的 JavaScript 代碼。這樣做有一個很大的弊端：瀏覽器兼容性。確實需要在每個流行的瀏覽器上測試 JavaScript 代碼中每個關鍵行 —— 或者至少，對客戶最可能使用的瀏覽器進行測試。所有這些都意味著大量的工作。以 清單 8 所示的復雜 Ajax 代碼為例。
清單 8. Antipat3_complex.html
<html><head><script> var req = null; function processReqChange() { if (req.readyState == 4 && req.status == 200 && req.responseXML ) { var dtable = document.getElementById( ‘dataBody‘ ); var nl = req.responseXML.getElementsByTagName( ‘movie‘ ); for( var i = 0; i < nl.length; i++ ) { var nli = nl.item( i ); var elYear = nli.getElementsByTagName( ‘year‘ ); var year = elYear.item(0).firstChild.nodeValue; var elTitle = nli.getElementsByTagName( ‘title‘ ); var title = elTitle.item(0).firstChild.nodeValue; var elTr = dtable.insertRow( -1 ); var elYearTd = elTr.insertCell( -1 ); elYearTd.innerHTML = year; var elTitleTd = elTr.insertCell( -1 ); elTitleTd.innerHTML = title; } } } function loadXMLDoc( url ) { if(window.XMLHttpRequest) { try { req = new XMLHttpRequest(); } catch(e) { req = false; } } else if(window.ActiveXObject) { try { req = new ActiveXObject(‘Msxml2.XMLHTTP‘); } catch(e) { try { req = new ActiveXObject(‘Microsoft.XMLHTTP‘); } catch(e) { req = false; } } } if(req) { req.onreadystatechange = processReqChange; req.open(‘GET‘, url, true); req.send(‘‘); } } var url = window.location.toString(); url = url.replace( /antipat3_complex.html/, ‘antipat3_data.xml‘ ); loadXMLDoc( url ); </script></head><body> <table cellspacing="0" cellpadding="3" width="100%"><tbody id="dataBody"> <tr> <th width="20%">Year</th> <th width="80%">Title</th> </tr> </tbody></table></body></html> |
這段代碼從 清單 9 所示的 XML 文件中讀取數據，然后將它變?yōu)楸砀窀袷健?/p>
清單 9. Antipat3_data.xml
<movies> <movie> <year>1993</year> <title>Jurassic Park</title> </movie> <movie> <year>1997</year> <title>The Lost World: Jurassic Park</title> </movie> <movie> <year>2001</year> <title>Jurassic Park III</title> </movie> </movies> |
可以看到如 圖 3 所示的結果。
圖 3. 復雜的電影清單頁面
這其實不是糟糕的代碼。只不過是用大量的代碼執(zhí)行一個實際上相當簡單的任務。產生的頁面一點兒都不復雜。它不能在客戶端對頁面進行排序和搜索。事實上，幾乎沒有理由對 XML 和 HTML 進行復雜的轉換。 難道不能像 清單 10 那樣讓服務器返回 HTML 而不是 XML，從而變得更簡單點兒嗎？
清單 10. Antipat3_fixed.html
<html><script> var req = null; function processReqChange() { if (req.readyState == 4 && req.status == 200 ) { var dobj = document.getElementById( ‘tableDiv‘ ); dobj.innerHTML = req.responseText; } } function loadUrl( url ) { ... } var url = window.location.toString(); url = url.replace( /antipat3_fixed.html/, ‘antipat3_content.html‘ ); loadUrl( url ); </script><body><div id="tableDiv"></div></body></html> |
事實上，這樣更加簡單。所有創(chuàng)建復雜表行和單元格的代碼被替換為頁面中 <div> 標記的一組簡單的 innerHTML。 Voilà! 從服務器返回的 HTML 如 清單 11 所示。
清單 11. Antipat3_content.html
<table cellspacing="0" cellpadding="3" width="100%"> <tbody id="dataBody"> <tr> <th width="20%">Year</th> <th width="80%">Title</th> </tr> <tr> <td>1993</td> <td>Jurassic Park</td> </tr> <tr> <td>1997</td> <td>The Lost World: Jurassic Park</td> </tr> <tr> <td>2001</td> <td>Jurassic Park III</td> </tr> </tbody> </table> |
對于所有任務，選擇是在服務器上處理，還是在客戶機上處理取決于任務的需求。本文的例子相當簡單：提供電影表。如果任務更復雜的話 —— 可能會進行分類、搜索、添加、刪除或動態(tài)交互（單擊電影名將出現更多信息）—— 那么可以在客戶端使用更加復雜的代碼。事實上，在本文的結尾我將演示在客戶機上進行排序，從而反面論證在服務器上施加大量負載的情形。 也許所有示例中最好的一個就是 Google Maps。Google Maps 執(zhí)行了很好的任務 —— 將富客戶端的代碼與服務器端的智能映射引擎結合了起來。我將使用這個服務作為例子，說明如何確定在哪里執(zhí)行什么樣的處理。
在應該傳送 JavaScript 代碼的時候卻傳送 XML 所有關于使 Web 瀏覽器讀取 XML 數據源并動態(tài)呈現它們的夸大其辭，可能讓您覺得這是惟一可用的方法。然而，這種想法是錯誤的，因為非常聰明的工程師已經使用過 Ajax 傳送技術來發(fā)送 JavaScript 代碼而不是 XML。請看 清單 12 所示的電影表示例。
清單 12. Antipat4_fixed.html
<html><head><script> var req = null; function processReqChange() { if (req.readyState == 4 && req.status == 200 ) { var dtable = document.getElementById( ‘dataBody‘ ); var movies = eval( req.responseText ); for( var i = 0; i < movies.length; i++ ) { var elTr = dtable.insertRow( -1 ); var elYearTd = elTr.insertCell( -1 ); elYearTd.innerHTML = movies[i].year; var elTitleTd = elTr.insertCell( -1 ); elTitleTd.innerHTML = movies[i].name; } } } function loadXMLDoc( url ) { ... } var url = window.location.toString(); url = url.replace( /antipat4_fixed.html/, ‘antipat4_data.js‘ ); loadXMLDoc( url ); </script></head><body> <table cellspacing="0" cellpadding="3" width="100%"> <tbody id="dataBody"><tr> <th width="20%">Year</th> <th width="80%">Title</th> </tr></tbody></table></body></html> |
這個示例沒有從服務器讀取 XML，它讀取的是 JavaScript 代碼。然后使用 JavaScript 代碼中的 eval() 函數獲取數據，然后再使用這些數據快速構建表。 清單 13 展示了 JavaScript 代碼。
清單 13. Antipat4_data.js
[ { year: 1993, name: ‘Jurassic Park‘ }, { year: 1997, name: ‘The Lost World: Jurassic Park‘ }, { year: 2001, name: ‘Jurassic Park III‘ } ] |
這個功能要求服務器使用 JavaScript 語言進行通信。不過這通常不是什么大問題。大多數流行的 Web 語言已經支持 JavaScript Object Notation（JSON）輸出。 優(yōu)勢是明顯的。在這個示例當中，通過使用 JavaScript 語言，下載到客戶機的數據減少了 52%。同樣，性能也得到了提升。讀取 JavaScript 代碼的速度快了 9%。9% 可能看上去不是很大，但是要記住這是個非常基礎的示例。更大的數據塊或者更復雜的結構需要更多 XML 解析代碼，而所需的 JavaScript 代碼數量不會變。
服務器負載過重 在服務器上執(zhí)行很少的任務的反面論證是在其上執(zhí)行大量的操作。正如我在前面提到的，這是一個需要權衡的問題。但是，我想說明的是如何在客戶機上對電影表執(zhí)行排序，從而為服務器減輕負載。 清單 14 顯示了可排序的電影表。
清單 14. Antipat5_sort.html
<html><head><script> var req = null; var movies = null; function processReqChange() { if (req.readyState == 4 && req.status == 200 ) { movies = eval( req.responseText ); runSort( ‘year‘ ); } } function runSort( key ) { if ( key == ‘name‘ ) movies.sort( function( a, b ) { if ( a.name < b.name ) return -1; if ( a.name > b.name ) return 1; return 0; } ); else movies.sort( function( a, b ) { if ( a.year < b.year ) return -1; if ( a.year > b.year ) return 1; return 0; } ); var dtable = document.getElementById( ‘dataBody‘ ); while( dtable.rows.length > 1 ) dtable.deleteRow( 1 ); for( var i = 0; i < movies.length; i++ ) { var elTr = dtable.insertRow( -1 ); var elYearTd = elTr.insertCell( -1 ); elYearTd.innerHTML = movies[i].year; var elTitleTd = elTr.insertCell( -1 ); elTitleTd.innerHTML = movies[i].name; } } function loadXMLDoc( url ) { ... } var url = window.location.toString(); url = url.replace( /antipat5_sort.html/, ‘antipat4_data.js‘ ); loadXMLDoc( url ); </script></head><body> <table cellspacing="0" cellpadding="3" width="100%"> <tbody id="dataBody"><tr> <th width="20%"><a href="javascript: void runSort(‘year‘)">Year</a></th> <th width="80%"><a href="javascript: void runSort(‘name‘)">Title</a></th> </tr></tbody></table></body></html> |
這是一個相當簡單的示例。它無法處理那些很可能需要好幾頁顯示的特別長的列表。但是它確實說明了創(chuàng)建一個能夠快速排序的表非常簡單，并且無需刷新頁面，也不需要服務器來執(zhí)行麻煩無聊的排序工作。
結束語 我針對 Ajax 編寫了大量文章，并做了大量 Ajax 工作，同時主持 IBM developerWorks Ajax 論壇，所以我了解一些關于 Ajax 的知識，以及其正確和錯誤的用法。最常見的情況就是開發(fā)人員低估了 Ajax 的復雜性，他們認為它只不過是向瀏覽器發(fā)送 XML、JavaScript 或 HTML 代碼而已。我將 Ajax 平臺視作完整的瀏覽器；實際上，是完整的流行瀏覽器集，因為您必須了解所有這些瀏覽器的特殊要求。 所有這些都歸結到一點：有大量的有關 Ajax 的知識要學習，在這個過程中還會發(fā)生很多錯誤。我希望這篇文章能夠幫助您避免一些這樣的陷阱，或者在落入這樣的圈套后幫助您解決麻煩?？傊m然可以從成功的經驗中學到很多知識，然而通常可以從錯誤中學到更多的東西。 | 
