Ajax Gotchas
Ajax陷阱
Ajax is an awesome technology that is driving a new generation of web apps, from maps.google.com to colr.org to backpackit.com. But Ajax is also a dangerous technology for web developers, its power introduces a huge amount of UI problems as well as server side state problems and server load problems.
Ajax是一項重要的技術，它將引領下一代web應用程序開發的風潮，從maps.google.com 到 colr.org 再到 backpackit.com ，處處充滿了ajax的倩影。但是對於web開發者來說，ajax也是一項危險的技術，它的力量也導致了一大堆UI問題，如服務器端狀態問題和服務器負載問題。
I've compiled a list of the many mistakes developers using Ajax often make. Javascript itself is a dangerous UI technology, but I've tried to keep the list to problems particular to Ajax development:
我編輯了一個開發者在使用ajax時經常犯的錯誤列表。Javascript本身就是一個危險的UI技術，但是我仍儘量使得這份列表只包含ajax開發中所遇到的問題，而剔除掉Javascript本身的問題。
Not giving immediate visual cues for clicking widgets. If something I'm clicking on is triggering Ajax actions, you have to give me a visual cue that something is going on. An example of this is GMail loading button that is in the top right. Whenever I do something in GMail, a little red box in the top right indicates that the page is loading, to make up for the fact that Ajax doesn't trigger the normal web UI for new page loading.
沒有及時給出點擊控件後的可視化提示信息。如果我點擊的這個東西觸發了ajax一個動作，那麼你必須給我一個可視化的提示，告訴我有些動作正在執行。一個例子就是Gmail頁面右上角的裝載按鈕（loading button）。無論何時，當我在Gmail中執行任何操作時，頁面右上角的小紅色按鈕就會提示我，頁面正在載入中。這樣明顯的向用戶提示出你的動作，從而克服ajax不再重載頁面而帶來的用戶不知操作是否進行的不便。
Coofucoo say：
習慣是可以培養的。就像用戶用慣windows時，就會習慣那個“開始”按鈕一樣，儘管剛開始他們會問：“爲什麼我想關機，還要從‘開始’處開始呢？”。當大多數web用戶習慣於頁面刷新即意味着數據提交這一傳統觀念時，一旦你打破這種觀念，你就一定要小心，儘量多的提示用戶你當前的操作，用戶就不至於感到莫名其妙，“到底這個該死的程序在幹些什麼？？！！”。反面例子你可以在球球的blog中找到。
Breaking the back button The back button is a great feature of standard web site user interfaces. Unfortunately, the back button doesn't mesh very well with Javascript. Keeping back button functionality is a major reason not to go with a pure Javascript web app.
Coofucoo say：
這是硬傷，似乎無解。我目前想到的解決辦法就是在程序裏自己提供一個後退按鈕，來代替瀏覽器提供的按鈕。不過這樣恐怕又會加大工作量。
破壞後退按鈕的功能。後退按鈕時標準web用戶界面的一個很重要的功能。但是不幸的是，後退按鈕的功能與Javascript結合的並不好。保持後退按鈕的功能也正是我們不採用純粹Javascript web應用程序的原因。
Changing state with links (GET requests) As I've referenced in a previous posting, Ajax applications introduce lots of problems for users who assume GET operations don't change state. Not only do state changing links cause problems for robots, users who are accustomed to having links drive navigation can become confused when links are used to drive application state changes.
竟然用鏈接來轉換狀態？（GET方式發送請求）就像我前面提到的一樣，對於一些認爲GET操作不會變更狀態的用戶來說，ajax應用程序導致了許多問題。那些可以改變狀態的鏈接不僅僅導致web應用程序使用習慣的變化，更容易使那些習慣的認爲鏈接就是起導航最用的用戶感到很困惑。
Coofucoo say：
感覺這個地方不好理解，解釋一下。超級鏈接最原始的功能就是在頁面之間進行切換，你由一個頁面點擊一個超鏈接，就會被帶到另一個地方。之後超鏈接有所發展，可以採用GET方法向服務器發送一些數據，不過有些用戶還是會認爲超鏈接的功能就是起導航的作用。但是現在情況變化了，在ajax裏，由於大量引入了Javascript事件，所以一個普通的超鏈接同樣可以起到原先button纔可以起到的作用，比如asp.net中的linkbutton。這樣也許會功能更強大，但是卻給部分用戶帶來了習慣和觀念上的變更，就會引入問題。
Blinking and changing parts of the page unexpectedly The first A in Ajax stands for asynchronous. The problem with asynchronous messages is that they can be quite confusing when they are pop in unexpectedly. Asynchronous page changes should only ever occur in narrowly defined places and should be used judiciously, flashing and blinking in messages in areas I don't want to concentrate on harkens back to days of the html blink tag.
頁面的某部分可能出乎意料的，一眨眼的就變化了。Ajax這組縮寫字母中的第一個字母“A”就代表了“異步（asynchronous）”。異步的信息所帶來的問題就是他們會悄無聲息的執行，毫無徵兆的突然彈出，讓人感到非常迷惑。異步頁面的變化部分應該被謹慎設計，明確說明，明智使用，提示的信息應該被放置在那些我不會全神貫注的地方，並且用例如blink標記這種技術讓他閃爍起來。
Not using links I can pass to friends or bookmark Another great feature of websites is that I can pass URLs to other people and they can see the same thing that I'm seeing. I can also bookmark an index into my site navigation and come back to it later. Javascript, and thus Ajax applications, can cause huge problems for this model of use. Since the Javascript is dynamically generating the page instead of the server, the URL is cut out of the loop and can no longer be used as an index into navigation. This is a very unfortunate feature to lose, many Ajax webapps thoughtfully include specially constructed permalinks for this exact reason.
超鏈接變得毫無意義，不能在傳遞給朋友或者收藏了。另一個web站點的重要功能就是你可以將一個URL傳遞給另一個人，而他就可以通過這個URL看到你看到的東西。當然，我也可以將這個URL放到我的收藏夾裏，以便我以後訪問他。Javascript，包括基於Javascript的ajax技術將會對這種應用模式帶來巨大的挑戰。由於Javascript取代了服務器，用來動態的產生數據，所以URL就不能具體代表整個交互循環的某個狀態點，也就不再能夠收藏了。這方面的功能缺失非常令人遺憾，許多ajax web應用程序在這方面考慮的非常仔細，包括專門構造一個特殊的鏈接（permalinks）來應對此種情況。
Too much code makes the browser slow Ajax introduces a way to make much more interesting javascript applications, unfortunately interesting often means more code running. More code running means more work for the browser, which means that for some javascript intensive websites, especially poorly coded ones, you need to have a powerful CPU to keep the functionality zippy. The CPU problem has actually been a limit on javascript functionality in the past, and just because computers have gotten faster doesn't mean the problem has disappeared.
太多的代碼讓瀏覽器變得緩慢。Ajax帶來了一種非常有趣的javascript應用程序，但是不幸的是，有趣也就意味着更多的代碼在運行。更多的代碼就意味着瀏覽器要做更多的工作，特別是有些不良的代碼雖然加強了功能，卻需要你有一個強勁的CPU去支持這些功能的實現。CPU不夠強勁實際上是過去限制javascript功能的一個重要因素，而且即使當下的計算機已經變得越來越快，這個問題也並沒有完全消失。
Inventing new UI conventions A major mistake that is easy to make with Ajax is: 'click on this non obvious thing to drive this other non obvious result'. Sure, users who use an application for a while may learn that if you click and hold down the mouse on this div that you can then drag it and permanently move it to this other place, but since that's not in the common user experience, you increase the time and difficulty of learning your application, which is a major negative for any application.
創造新的UI使用習慣。使用ajax很容易犯這樣的錯誤：“想當然的要求用戶去點擊一個不明顯的東西，然後再一個不明顯的地方將結果返回給用戶”。誠然，當一個用戶使用你的程序一段時間，他就可以瞭解到，如果他將鼠標在一塊區域上點擊，並且保持按下的狀態進行拖拽，就可以將這塊區域永久的移動到另一個位置。但是這些經驗並不是每個用戶天生就知道的，如果你這麼做，那麼你就爲你的用戶學習使用你的應用程序增加了難度和時間，而這樣的情況對於大多數應用程序來說都有極大的負面影響。
Not cascading local changes to other parts of the page Since Ajax/Javascript gives you such specific control over page content, it's easy to get too focused on a single area of content and miss the overall integrated picture. An example of this is the Backpackit title. If you change a Backpackit page title, they immediately replace the title, they even remember to replace the title on the right, but they don't replace the head title tag with the new page title. With Ajax you have to think about the whole picture even with localized changes.
當局部發生變化時，可能需要成串同步頁面其他部分。從Ajax/Javascript賦予你控制（更改）頁面具體內容的時候，就特別容易犯下只注重局部數據變化，而忘記在整個頁面同步該變化的錯誤。一個例子就是Backpackit（http://www.backpackit.com/）的標題。如果你執行了一個改變Backpackit頁面的動作，標題會被立刻改變過來，甚至右邊的標題也會被一起變化，但是他們忘記了爲新頁面同步位於<head>標籤中的<title>標記。在ajax裏，當你更改局部時，你需要考慮整個頁面的同步問題。
Asynchronously performing batch operations Sure with Ajax you can make edits to a lot of form fields happen immediately, but that can cause a lot of problems. For example if I check off a lot of check boxes that are each sent asynchronously to the server, I lose my ability to keep track of the overall state of checkbox changes and the flood of checkbox change indications will be annoying and disconcerting.
分批異步執行操作帶來的問題。確實，在ajax裏你可以編輯許多不同的表單，並且表單會及時提交，但是這樣也帶來了許多問題。例如，我編輯了一些一些複選框，每個都可以異步的單獨將數據提交給服務器，但是同時我卻喪失了在整體上控制這些複選框狀態的能力，並且每個複選框提交之後返回結果的提示信息也會變得非常令人討厭。
Scrolling the page and making me lose my place Another problem with popping text into a running page is that it can effect the page scroll. I may be happily reading an article or paging through a long list, and an asynchronous javascript request will decide to cut out a paragraph way above where I'm reading, cutting my reading flow off. This is obviously annoying and it wastes my time trying to figure out my place.
另一個問題是，即時向一個正在運行的頁面寫入內容可能會導致頁面滾動。我可能會比較喜歡閱讀一篇全部顯示出來的文章，儘管文章可能會很長。可是一個異步的javascript程序也許會將我所讀過的部分丟掉，從而影響我的閱讀。當我試圖再次找回我之前閱讀的位置時，這種機制會顯得特別不方便。
In addition, some programming issues:
另外，還有些編程的問題：
Be careful about what you expose on the server, especially if you're using remote-stub frameworks like SAJAX. You can't necessarily let Javascript use generic services that you might let a server-side script call. Don't rely on a global XMLHttpRequest object. See Call Tracking.
Coofucoo say：
這個地方我沒有翻譯出來，對他描述的情況知道得不是很確切。哪位知道得拜託通知一下。
Be careful about changing the DOM in one call, such that when a later call returns, it ends up writing a value into the wrong DOM object - or perhaps the DOM object doesn't return at all (To be added to [[Call Tracking).
當你響應一個調用而更改DOM的內容時，一定要小心，如果此時稍後的一個調用返回，很可能會導致將數據寫入錯誤的DOM對象中，或者可能導致對DOM對象的操作根本就不返回。
Consider the effects of a call never returning. You can establish a timeout mechanism by setting a timer as soon as the call is made (with Javascript's ontimeout function). The timer can explicitly call the request's abort() method if no return has occurred, and inform the user accordingly.
考慮調用沒有返回的情況。你可以通過在函數調用後設置一個timer（用Javascript的ontimeout函數）來建立一個超時機制。如果沒有返回的話，這個timer就可以明確地執行abort()（終止操作），並且通知用戶。
Consider the effects of a call returning with an error status - perhaps alert the user somehow. A pattern like Synchronisation Status helps here, to alert the user that some data is stale.
考慮調用返回一個錯誤狀態的情況，這種情況下可能會提示用戶一些莫名其妙的信息。像Synchronisation Status這樣的模式就可以在這裏爲我們提供幫助，警告用戶有些數據已經出問題了。