單頁介面和 AJAX 模式

轉自MSDN http://msdn.microsoft.com/zh-cn/magazine/cc507641.aspx作者：Dino Esposito

代碼下載位置: CuttingEdge2008_05.exe (203 KB) Browse the Code Online

 目錄 AJAX 模式的影響 單頁介面模型 單頁介面模型的缺點 可訪問的富 Internet 應用程式 AJAX 模式概述 唯一 URL 模式 逾時模式 與當今構建的絕大多數 Web 應用程式所採用的開發模式相比，AJAX 對 Web 解決方案架構師而言意味著一種模式轉變。它立足於一些新的原則和規則來解釋基於 Web 的系統的行為，並要求採用一些新的演算法來實現它們。AJAX 背後的主要原則是使用者將純資料發送到 Web 服務器，然後接收更多的純資料。AJAX 的第二個原則是使用者自行協調操作，這將略過主機瀏覽器及其單頁面請求/響應機制。第三個 AJAX 原則是用戶端代碼利用從伺服器接收到的純資料來全面負責對使用者介面的更新。本專欄將為那些準備完全擺脫防禦性 AJAX 實現（表現為部分呈現）的開發人員奠定基礎。部分呈現是一種在處於 Web Form體繫結構中時仍可實現某些 AJAX 功能的途徑。AJAX 模式基於一種全新的原則，這種原則要求採用新的設計模式。AJAX 模式的影響ASP.NET 部分呈現是一種非常智能的新增內容，它屬於傳統的 Web Form回傳模型。簡而言之，使用部分呈現的頁面其回傳體繫結構和頁面生命週期與非 AJAX 頁面中的完全相同（請參見 圖 1）。不同之處在於位於用戶端的接聽程式只阻止瀏覽器的預設操作（表單提交），並用 XMLHttpRequest 引導的 HTTP 要求來替代它（請參見 圖 2）。此方法不但可以節省使用者的整頁重新整理時間，同時還可以節省開發人員在新體繫結構和新模式培訓方面所花的時間。圖 1  傳統的整頁回傳操作 (單擊該映像獲得較大視圖)圖 2  AJAX XMLHttpRequest 部分呈現 (單擊該映像獲得較大視圖)毋庸諱言，部分呈現在當前頁面的上下文中提供了圖形化優勢。但是，如果您的應用程式是圍繞一組獨立的頁面設計的，那麼從一個頁面到下一個頁面的過渡仍需要整頁載入。部分呈現非常適合於替換內部頁面回傳，例如，對網格進行分頁、變更選擇後調整使用者介面或就地編輯記錄。由於部分呈現只是一種更智能形式的頁面回傳，因此它具有與 Web Form模型相同的體繫結構限制。例如，每個瀏覽器視窗只能有一個待決請求。對於當前的 Web 應用程式（提交表單、擷取新頁面）模型而言，此限制可能不會產生太大問題。但是，隨著您對 AJAX 認識的拓展，自然而言就會期望使用者可以同時執行多個活動。僅依靠部分呈現，使用者是無法同時執行兩個非同步作業並將其完成的。部分呈現只能每次執行一個請求操作以保持檢視狀態的一致性（一致性仍是模型不可或缺的組成部分）。這嚴重違背了 AJAX 中的第一個要求：非同步。使用部分呈現（帶外執行），可以實現 JavaScript 驅動的回傳，但每次只能有一個。如果在前一個操作完成之前觸發了第二個操作，則待處理操作將被中止，以便新操作可以繼續執行。可通過編程方式將這一後進得勝策略改為先進得勝模型，從而使當前操作仍保持活動狀態，而新操作將被系統取消 — 實質上這仍然是每次只能執行一個操作。單頁介面模型為了充分利用 AJAX，必須在單一頁面中包含其中的全部功能，或者是至少包含大部分功能。這稱作單頁介面 (SPI) 模型。在 SPI 模型中，瀏覽器與 Web 應用程式的所有互動只能在一個頁面的範圍內進行。此方法對 Web 來說是一種創新，但對於 Windows 和案頭開發卻並不陌生。SPI 其實模型就像是具有主（並且唯一）視窗的 Windows 應用程式一樣。在 SPI 模型中，首頁面是可以獨立載入、更新和替換的一些可視元素的組合（請參見 圖 3）。通過這種方式，可以不必在每次使用者操作後重新載入整個頁面。在任何時候，都只顯示與應用程式當前階段相關的可視元素和內容。其他所有內容均被隱藏；但只要應用程式流程程中需要用到它，它就會顯示出來。圖 3  頁面中的單頁介面元素 (單擊該映像獲得較大視圖)SPI 模型自然會啟用許多互動性很強的功能，其中包括就地編輯、上下文相關的使用者介面、即時使用者反饋提示以及非同步作業等。但 SPI 模型並不僅僅具有出色的效能或響應能力，它的主要優勢在於針對使用者體驗方面做的重大改進。不過，即使它擁有如此多的優點，您還是應該清楚，使用 SPI 模型設計新應用程式是一項具有挑戰性的工作，因為沒有任何現成的模式和最佳實務。目前的結論是有一種使用 AJAX 的簡單方法，它適合於眾多公司和多種情況。而當前主流的 AJAX 使用方法不太便利。為了構建純 AJAX 應用程式，您需要一個良好的使用者介面小工具庫來提供各種效果和特殊行為。您需要一個內容豐富而又可以自訂的文件物件模型 (DOM)，此模型使用標準的全球資訊網聯盟 (W3C) DOM 作為其基礎引擎，但它允許您定義自己的特定應用程式的模型。最後，您還需要一個伺服器和用戶端架構，以便輕鬆有效地開發使用者介面和原始碼指令碼。最好還準備一些用於調試和測試所有這一切的工具。Microsoft 和其他一些供應商提供了部分這樣的工具。有許多 UI 小工具庫可供您選擇，此外還有一些供應商，它們生產各種用來定義其各自用戶端物件模型的控制項。而真正有協助的則是改進後的專門設計用作 Web Form備選模型的 AJAX 架構，它的靈感源自 SPI 模型。其中一個此類替代編程模型是模型視圖控制器 (MVC) 架構，在 ASP.NET 3.5 擴充庫中可以找到它。但就目前來看，它並沒有太多值得 AJAX 借鑒的內容，雖然它不會阻止任何 AJAX 功能的實現，但它也似乎沒有發展成為 SPI 模型的打算。不過時間會證明一切的。在 SPI 模型中，首頁面指向同一應用程式中的 HTTP 端點。它執行遠程代碼，但不會重新載入整個頁面。而且，它還會使用產生 HTML 和指令碼的控制項來更新使用者介面。這些控制項非常智能，可以產生它們需要的許多 JavaScript 代碼。例如，假定有一個用來預訂航班的表單，其中可能有兩個參數需要搜尋：時間或成本。如果使用者對便宜的航班更感興趣，那麼您就不必顯示時間下拉式清單。如果使用者需要在準確的時間起飛，那麼您就必須調出顯示時間的 HTML。很明顯，只需要一些 JavaScript 就可以輕鬆實現這種顯示/隱藏技巧。但是現在，這些代碼需要由頁面開發人員來負責編寫。ASP.NET AJAX 控制項工具包 (asp.net/AJAX/AjaxControlToolkit/Samples/CollapsiblePanel/CollapsiblePanel.aspx) 中提供的控制項（如 CollapsiblePanel 控制項）也可以協助實現此操作。單頁介面模型的缺點雖然 SPI 模型（及其包含的整個 AJAX 模式）帶來了互動性更強的使用者體驗，但同時也引發了諸多問題，例如可搜尋性、曆史管理、可訪問性和離線支援等。多年以來，一直使用永久連結來跟蹤 Web 頁面。搜尋引擎只需將一組關鍵字映射到一個或多個 URL 即可構建其業務。此模型的工作前提是假設 Web 應用程式中每個狀態都對應一個頁面和一個不同的 URL。如果 SPI 模型處在 AJAX 中，則此假設不再有效。如果所有一切（或大部分）都發生在同一頁面中，則沒有 URL 轉換來標記不同的狀態和不同的網站內容。因此，沒有將內容（和關鍵字）與唯一 URL 相關聯的簡單方法。SPI 模型的這一特性會影響可搜尋性以及曆史管理（例如，使用“後退”和“前進”按鈕的能力）。瀏覽器記錄最終可能會變為過時的概念，它們是傳統靜態 Web 模型的搭檔。但是您必須要知道，使用者對這些按鈕實在是太熟悉了，簡單地禁用它們並不是一個可行的辦法。可訪問性是 AJAX 應用程式的另一個大問題。大多數流行的螢幕讀取器在處理通過 DOM 指令碼產生的任何內容時都面臨很大的困難。按照設計，所有形式的 AJAX（包括部分呈現）都嚴重依賴於 DOM 指令碼。因此，您需要通過其他途徑來解決可訪問性問題。Web Content Accessibility Guidelines (WCAG) 中的第 508 節建議，只要頁面利用指令碼語言來顯示內容或建立可視元素，它所提供的替代功能文本就應該可以通過輔助技術加以訪問。為符合此建議，需要使用 <noscript> 標記。當前，大多數 AJAX 架構都在頁面內部進行動態更新，而不更新 <noscript> 標記中包含的靜態資訊。可訪問的富 Internet 應用程式此問題看起來好像是雙重的，既涉及 AJAX 應用程式，又涉及螢幕讀取器背後的技術。一方面，螢幕讀取器要瞭解一些用戶端事件，如 onclick、keypress 和 readystatechange 等。在螢幕讀取器中弄清了這些事件後，便可以至少將第一個可訪問層添加到大量基於 AJAX 的應用程式中。另一方面，如果螢幕讀取器超出了 DOM 中的初始頁面載入事件範圍，它們通常不會發出任何新資訊。但您可以使用一些技巧讓螢幕讀取器知道有些內容已經發生了變化。最有效一招就是在更新後的 DOM 樹的根目錄將 tabindex 設定為 -1。但這隻是一個小技巧，可訪問性的解決需要更為通用的 AJAX 解決方案。其中的一種可行解決方案是 W3C 正在制定的被稱為“可訪問富 Internet 應用程式”(ARIA) 的新標準，它主要由 HTML 標籤的特定讀取器向外延展群組成。一些比較流行的用戶端 AJAX 庫已經開始支援某些 ARIA 功能了。但一般來說，這並不僅僅是有關 AJAX 可訪問性相容標準的可用性問題。它還常常涉及伺服器控制項實際產生的內容（標記和指令碼）。對於離線應用程式是怎樣的情況？許多開發人員認為離線 AJAX 應用程式不可能實現，因為 AJAX 應用程式仍然完全基於 Internet。在我看來，這種說法雖然並非完全錯誤，但也有點過於簡單化了。現在，幾乎所有 Web 應用程式（AJAX 和非 AJAX）都基於 Internet 或 intranet。但是，非 AJAX 應用程式的確可以離線工作。例如，對於記錄管理，啟用離線導航的魔力完全在於瀏覽器。在傳統的 Web 應用程式中，每個 HTTP 要求都由瀏覽器來管理。如果沒有可用串連（在引發 HTTP 404 錯誤之前），瀏覽器會在其本地頁面緩衝中進行尋找。AJAX 應用程式不同於傳統的 Web 應用程式，它使用 XMLHttpRequest 對象而非瀏覽器引擎來發送 HTTP 要求。對於支援離線情況的 AJAX 應用程式，您只需為 XMLHttpRequest 對象賦予訪問瀏覽器緩衝的許可權或賦予建立並管理其自身已訪問頁面的緩衝的能力即可。某些 AJAX 架構已開始引入此功能。但這並非是一件容易的事，因為它涉及從 JavaScript 代碼訪問磁碟。AJAX 模式概述下一代基於 Web 的應用程式將直接面向 AJAX，而且會更多直接面向富 Internet 應用程式 (RIA)。起初，引領這一革新版本的是以下三大類應用程式：基於 HTML 的傳統網站、為了將多個系統整合到一個基於 Web 的前端而構建的混合應用程式、胖用戶端。對於第一個類別，部分使用者介面載入（部分呈現）是實現 AJAX 的一種簡便方法，它對現有代碼和技能的影響非常小。而混合程式的概念本身未必適合於 AJAX 和改進的使用者互動。它只是一種從各種來源收集資料並將其一併放入一個統一而又一致的使用者介面中的方法。此操作也可以在傳統的伺服器對伺服器的情況下執行。但是坦率地說，AJAX 可以使其更加簡單有效。從 AJAX 角度看，混合應用程式需要標準的資料序列化格式（整合）、用於通過指令碼調用遠程服務的輕量級架構、可更新的 DOM，可能還有一些具有方便的編程模型的富可視控制項。使用 AJAX 構建胖用戶端是一個最嚴峻的挑戰。胖用戶端可以是分布式企業系統的前端，也可以是企業營運系統應用程式的表現邏輯層。它還可以是 IT 部門決定作為 Web 應用程式而公開的獨立應用程式。這些應用程式無論是發布到 Internet 上還是限制在 intranet 內，都需要常規案頭 UI 所具有的豐富性和速度。與 Windows 開發相比，在互動性和響應性方面 Web 開發都是一種倒退。利用 AJAX，您最終可以使用其中的工具（和環境條件）向本質上不同的模型演化。但其中存在著不容忽視的折衷。一方面，有數百萬的使用者和開發人員已習慣了使用舊的 Web 及其曆史模式、離線導航、收藏夾、單一操作、頁面轉換和永久連結等。另一方面，您採用的卻是 AJAX 及其並行操作模式和單一自動更新使用者介面功能。在這種情況下，對於使用者任務，AJAX 模型需要真正的恢複模型，而不僅僅是使用瀏覽器的記錄和頁面導航功能。要對 SPI 模型編寫代碼，需要使用一組新的設計模式。 圖 4 列出了一些最流行的 AJAX 模式。正如您所看到的，其中大部分都側重於使用者介面技術和排列，但您也應該注意到，此列表中並不包括一些已在 Microsoft AJAX 用戶端庫中實現的 AJAX 流行模式和實踐。例如，如果您使用 ASP.NET AJAX，則不需要 AJAX 存根、跨瀏覽器 JavaScript 模型或調用跟蹤模型，因為所有這些功能都是預置的。 Figure 4 一些 AJAX 模式

模式	目標
瀏覽器端模板化	此模式建議使用 HTML 範本，它們將使用從遠程 HTTP 端點檢索的資料動態填充。此模式建議您設定自己的模板層，而不要基於每個請求動態為資料重建 HTML 布局。此模式是 HTML Message 模式的替代方案。
跨域代理	此模式對可訪問的、公開提供的服務運行伺服器到伺服器串連，並將資料傳回用戶端。在用戶端瀏覽器中，不允許 AJAX 應用程式串連到頁面域外部的任何 URL。但是，同一域內的本地代理可以輕鬆地從任何位置擷取資料並將其返給調用方。
活動訊號	由於許多 AJAX 應用程式可能會在用戶端執行大量操作而不傳回資訊，因此可能需要通知伺服器指定用戶端仍處於活動狀態。此模式建議用戶端應用程式要定期上傳“活動訊號”訊息，以指示應用程式仍在載入狀態並在瀏覽器中正常運行。
HTML 訊息	遠程 HTTP 端點通常會返回要整合到現有 DOM 中的用戶端 JavaScript Object Notation (JSON) 資料。此任務只能通過 JavaScript 來完成。但是，如果用戶端代碼特別複雜或考慮到效能問題，您可能希望從伺服器返回 HTML（資料和布局）而不是純資料。
微連結	AJAX 主要用於在同一頁面內執行大量活動。那麼如何引用外部內容（即在傳統 Web 應用程式中會轉到不同頁面的內容）？您需要一種頁內超連結或稱為微連結。微連結是對標記塊的引用，它通過伺服器調用進行檢索然後再插入到頁面中。微連結可以是 HTTP 端點，也可以是 JavaScript 命令對象的方法。
點播 JavaScript	這是流行的消極式載入模式的 JavaScript 版本，通常用於資料訪問層。在頁面初始化過程中下載所需的全部 JavaScript 可能會對效能產生影響，從而拖慢整個進程。通過採用按請求來載入 JavaScript 檔案的方法，可以使頁面獲得更快的載入速度，同時還不會對功能產生影響。
頁面安排	由於大部分應用程式的活動都發生在同一個頁面中，因此您需要更新頁面的內容並隨著上下文內容的變化來顯示最新資訊。此模式只建議您使用 DOM 來添加/刪除或顯示/隱藏元素以反映其狀態的轉換。
定期重新整理	瀏覽器會定期安排請求以獲得最新資訊，並用它來重新整理使用者介面。
彈出框	此模式代表 Web 版本的模式/無模式 Windows 對話方塊。彈出框由一些 HTML 內容組成，它們顯示在現有內容的前面，顯示時間可以很短，也可以一直顯示直到使用者將其取消。
預模數式	此模式建議預測最可能的使用者操作並預先擷取所需的資料。實現此模式需要付出一定的代價：畢竟它只是猜測，有時可能會預測錯誤。儘管可以有效地提高感知效能，但如果實現效果不佳或者由於嚴重的伺服器頻寬損耗致使達不到理想情況，則此模式也可能會帶來效能損失。
進度列指示器	此模式用來監視伺服器操作的進度。其思路是，伺服器操作將其自身的進度寫入一個共用位置，而用戶端監控服務則可在進度重新整理時進行讀取。
提交限制	AJAX 的其中一個潛在缺陷是在單位時間內可能會產生過多的伺服器請求。如果出現這種情況，則說明存在著明顯的延展性問題。此模式建議您使用定時器將資料定期上傳到伺服器和本機快取或隊列中，以將請求累積起來。
逾時	如果從用戶端執行一些重量級操作（如流式或定期重新整理），則要想保證每個串連的用戶端都真正使用此應用程式會有一些困難。此模式建議您使繁重操作逾時，在使用者提出明確請求時再恢複。
唯一 URL	對於反映不同狀態的應用程式的不同部分，此模式允許您為其分配不同的 URL。此模式通常用於支援 AJAX 應用程式中的記錄。
虛擬工作區	伺服器需要儘快響應請求，但由於頻寬原因，它可能不必返回所有可用的資料。此模式建議構建一個虛擬使用者介面，即使資料在用戶端只存在一小部分，也可以實現使所有資料都可用的目的。應用程式會負責根據需要下載資料並將其緩衝到本地。

您還應注意，在 圖 4 列出的模式中（一般為 AJAX 模式），參考模式要多於設計模式。它們指出了常見的操作執行方法，但並非它們都是設計問題。在 圖 4 中，我簡要概述了每個模式的要點。在本專欄的剩餘部分，我要對其中的部分模式進行深入的分析。在以後的專欄中，我將回到其他一些重要模式，討論其驅動力並示範一些執行方法。（要瞭解有關 AJAX 模式的詳細資料，可以訪問一個非常出色的網站 ajaxpatterns.org。）唯一 URL 模式URL 是 Web 的基礎。使用者可以將中意的 URL 儲存下來以供將來參考、可以按照 URL 所指開始新的內容體驗，此外還可以使用 URL 回到先前的狀態。在 AJAX 和 SPI 模型中，應用程式可以在單個 URL 中完成許多任務。這將使 Web 體驗的核心支柱面臨徹底的改變，即：應用程式的離散狀態是由不同的 URL 來標識的。瀏覽器會在使用者瀏覽時構建其各自的 URL 緩衝。但如果使用 AJAX，許多操作都不通過瀏覽器，因此不會被緩衝到訪問過的 URL 列表中（在此列表中可驅動“後退”和“前進”菜單）。另一方面，用戶端瀏覽器不會提供將 URL 添加到列表中的 JavaScript 代碼編程模型。在現有列表中，瀏覽器物件模型只會提供向前和向後的導航方法。“唯一 URL”模式為每個重要的應用程式狀態都分配一個唯一的、含義鮮明的 URL。例如，如果使用者在 AJAX 頁面中通過單擊來編輯某個值，則新 URL 會被添加到瀏覽器緩衝中，即使此操作是通過 XMLHttpRequest 在同一頁面中執行的。可使用以下 JavaScript 來更改 URL 而無需重新載入頁面： 複製代碼

window.location.hash = stateInfo;

此代碼的作用是將以 # 作為首碼的片段添加到 URL 中，如下所示： 複製代碼

http://www.contoso.com/shopping.aspx#edit-1234

使用此模式時，URL 實際上是在您啟動任何給定的 AJAX 操作時發生改變的，因此可以通過瀏覽器來跟蹤應用程式狀態的變化。但是，要執行的操作遠不止捕獲 URL 這樣簡單。如果瀏覽器被定向到基於雜湊值的 URL，它首先會載入主 URL，然後再尋找具有此雜湊名稱的頁面段。在 AJAX 上下文中，雜湊名稱並不指向實際的頁面段，而是指向代表目前狀態的特定於應用程式的資訊。例如，edit-1234 可能表示您正在編輯的項目其 ID 是 1234。實際格式完全取決於您。如果瀏覽器找不到適當的段，則它將忽略 URL 雜湊值。這樣，使用者會載入該頁面，但可能不是以預期的應用程式狀態。此外還需要另一個技巧。您應截取頁面的 onload 事件、分析 URL、提取雜湊值並運行將頁面置於期望狀態所需的 JavaScript 代碼，如下所示： 複製代碼

window.onload = function() {    checkAndParseURL();} checkAndParseURL() {     var state = window.location.hash;     restorePage(state);}

在 ASP.NET 3.5 擴充所提供的記錄支援中也採用了類似的方法。您可以訪問 quickstarts.asp.net/3-5-extensions/ajax 瞭解更多相關資訊。ASP.NET 3.5 擴充中的解決方案已完全整合到此架構中。它將以添加到 ScriptManager 控制項的新屬性和事件的形式顯示出來。但最終，它將是“唯一 URL”模式的具體實現。另外還應注意，基於 URL 雜湊值的技巧對 Internet Explorer 無效，因為 Internet Explorer 無法識別出 URL 雜湊值的變化，除非是內嵌幀。實際上，所有瀏覽器在處理段導航方面所表現出的行為特點都是互不相同的（有關本主題的詳細資料，請參閱 weblogs.asp.net/bleroy/archive/2007/09/07/how-to-build-a-cross-browser-history-management-system.aspx）。ASP.NET 3.5 擴充中的解決方案考慮到了此差別，這使得它成為真正的跨瀏覽器技巧。逾時模式AJAX 的其中一個最大優點是可以實現即時頁面更新。但是，即時更新如果被誤用，可能會成為應用程式的嚴重威脅。假設某個使用者顯示了一個活動頁面，此頁面每隔幾秒鐘輪詢一次伺服器以更新一些內容。如果該使用者離開幾個小時，但沒有關閉瀏覽器。這樣做產生的結果是，頁面不斷髮送請求，給伺服器帶來大量（而且無用）的工作負載。如何能夠確定用戶端工作階段是否逾時？在伺服器上存在著會話逾時，而在 AJAX 中也存在著不容忽視的用戶端工作階段。要檢測用戶端工作階段的結束，您需要檢查在給定時間段內是否有使用者活動（例如單擊和敲擊）。監視鍵盤和滑鼠活動的任務可能會非常繁重；我們通常都採取一種基於定時器的方法，這種方法不但簡單而且很有效。要根據定時器檢測會話的結束，應將用戶端定時器設定為經過指定秒數（實際當中更有可能是分鐘數）之後到期、停止正在執行的任務並彈出一個警告框。如果使用者對提示做出響應，則會照例重新開始處理。 圖 5 顯示了部分 JavaScript，它描述了逾時模式的本質。在樣本頁中嵌入了一個時鐘。此時鐘可使用 UpdatePanel 中的 Label 控制項來擷取，並由 Timer 控制項定期更新，如下所示： Figure 5 實現用戶端工作階段逾時 複製代碼

<script type="text/javascript">    var timer = null;    function pageLoad()    {        if (timer === null)        {            timer = new Samples.TaskTimer(5000, stopTask);            timer.start();        }    }    function pageUnload()    {        if (timer != null)            timer.stop();    }        function stopTask()    {        // Stop the clock         var clock = $find("<%= Timer1.ClientID%>");        clock._stopTimer();                AskIfTheUserWantsToContinue();    }        function AskIfTheUserWantsToContinue()    {        // Ask if the user wants to continue        var answer = window.confirm(          "Is it OK to continue with the clock?");        if (answer)        {            // Restart the task              var clock = $find("<%= Timer1.ClientID%>");            clock._startTimer();                        // Restart our own timeout engine            if (timer !== null)                timer.start();            return;        }            }</script>

複製代碼

protected void Timer1_Tick(object sender, EventArgs e){    Label1.Text = DateTime.Now.ToLongTimeString();}

此時鐘代表一項繁重的任務，可能會造成伺服器請求溢出。其思路是設定一個定時器，定期詢問使用者是否確實想要繼續運行時鐘。逾時代碼首先會停止時鐘，然後顯示訊息框。得到使用者響應後，時鐘重新啟動。此代碼利用 $find 函數來定位 ASP.NET AJAX 組件，在本例中，它還是 ASP.NET 定時器伺服器控制項的用戶端物件模型。 圖 6 顯示的是正在啟動並執行頁面，它會彈出一個框，詢問使用者是否確定繼續。圖 6  詢問使用者是否繼續 (單擊該映像獲得較大視圖)

請將您想向 Dino 詢問的問題和提出的意見發送至 cutting@microsoft.com。 cutting@microsoft.com.

Dino Esposito 是《Programming ASP.NET 3.5 Core References》 的作者。Dino 定居於意大利，經常在世界各地的業內活動中發表演講。您可加入他的部落格，網址為 weblogs.asp.net/despos。