擁抱變化——從Atlas到ASP.NET AJAX（2）：變化得翻天覆地的ScriptManager（Dflying仍有好多疑問，請指教）

閱讀本文之前，您需要安裝完成Microsoft ASP.NET AJAX v1.0 Beta以及Microsoft ASP.NET AJAX CTP Beta，其中後者依賴於前者，需要注意安裝順序（詳見擁抱變化——從Atlas到ASP.NET AJAX（1）：下載安裝總覽）。安裝完成之後，Visual Studio中建立Web Site的時候會多出兩個模版：ASP.NET AJAX Enabled Web Site和ASP.NET AJAX CTP Enabled Web Site，其中前者是最基本的Microsoft ASP.NET AJAX v1.0 Beta網站，後者為基於前者的擴充，即Microsoft ASP.NET AJAX CTP Beta網站，包含了多個附加的控制項（這些也都在原有的Atlas中）。順便提一下，Microsoft.Web.Extensions.dll，也就是Microsoft ASP.NET AJAX v1.0 Beta的DLL在安裝過程中將被自動添加到了GAC中，這也正是建立ASP.NET AJAX Enabled Web Site之後該網站的bin檔案夾為空白的原因。而Microsoft.Web.Preview.dll，也就是Microsoft ASP.NET AJAX CTP Beta的DLL沒有添加在GAC中，所以建立了ASP.NET AJAX CTP Enabled Web Site之後，bin檔案夾下會包含該DLL。

接下來的內容均將基於一個建立的ASP.NET AJAX Enabled Web Site。

在ASP.NET AJAX中，ScriptManager控制項依然作為最核心的組件存在於頁面中，負責將用戶端實現Ajax功能的JavaScript指令碼發送至瀏覽器。但從Atlas到ASP.NET AJAX的過程中，ScriptManager的變化卻可以稱得上是改頭換面，幾乎顛覆了我們所熟悉的所有的從前的Atlas中ScriptManager的概念。

ASP.NET AJAX的用戶端指令碼庫檔案均大大減小，看來微軟確實意識到了Atlas的不足：

1. MicrosoftAjax.js   67KB
2. MicrosoftAjaxRuntime.js   15KB
3. MicrosoftAjaxWebForms.js    32KB
4. PreviewDragDrop    42KB
5. PreviewGlitz.js    14KB
6. PreviewScript.js    183KB

其中前三者為Microsoft ASP.NET AJAX v1.0 Beta中的核心指令碼庫，後三個為Microsoft ASP.NET AJAX CTP Beta中的附加指令碼庫。注意到AtlasCompact.js和AtlasCompact2.js這兩個瀏覽器安全色層檔案都沒有了，一切都整合在了MicrosoftAjax.js中。

注意：本文內容很多均為我今晚學習的個人見解，尚未經過完善的驗證，並在文中也提出了許多問題，希望朋友們能夠協助解決。

讓我們從聲明ScriptManager的標籤開始逐一說明其變化：

<asp:ScriptManager>標籤

首先需要注意的是原有的“altas”首碼被改為了“asp”。據說是為了和現有的ASP.NET“無縫”對接，我卻不以為然，畢竟不同的首碼更易於區分。

添加一個最簡單的<asp:ScriptManager>之後，將有3個指令碼通過axd資源檔引入到用戶端：MicrosoftAjax.js、MicrosoftAjaxWebForms.js以及一個另外JavaScript檔案（問題：這是什麼東西？到底有什麼用？）。

另外一個問題是，這個精簡版本的MicrosoftAjaxRuntime.js應該如何使用？<asp:ScriptManager>標籤中似乎並沒有提供使用該指令碼的設定選項？難道只能手工引入嗎？

放下這兩個問題，看一下<asp:ScriptManager>標籤所支援的屬性：

1. AllowCustomError：在非同步更新發生異常時是否使用Web.config中<customErrors>這一節的設定。<customErrors>中可以指定應用程式層級的錯誤處理頁面，如果我們比較懶，則可以設定該屬性為true，讓發生異常後和普通ASP.NET程式一樣重新導向至某個專門顯示錯誤的頁面。一般來講，最好設定其為false，因為這是Ajax程式，頁面跳轉是我們應該竭力避免的。
2. AsyncPostBackErrorMessage：非同步更新發生異常時發送給用戶端的錯誤資訊，可以在AsyncPostBackError事件的處理函數中根據異常的不同而動態設定該資訊。然後用戶端Web Form架構就可以格式化並顯示給使用者，這也是我推薦的Ajax異常處理方式。
3. AsyncPostBackTimeout：非同步更新的逾時時限，單位為秒，預設值為90。沒啥多說的，沒事就別改了。
4. EnablePartialRendering：（終於看到一個在Atlas中曾經有的屬性了，好激動……）是否支援頁面局部更新，預設值改為true，這樣在用UpdatePanel的時候就不必每次都要留意設定ScriptManager的該屬性了，不過也自然地帶來了效率上的輕微影響。究竟何種方式最好，也是謂仁者見仁，智者見智的問題。
5. ScriptMode：指定使用用戶端指令碼的版本（Debug或者Release），該屬性的設定結果同樣受制於設定檔中retail相關設定，詳請參考http://ajax.asp.net/docs/mref/332fcb41-e4ab-4c1f-bb5e-61b49035af74.aspx 。需要注意的是對於自訂指令碼，若該屬性設定為Debug或程式實際運行時被認為需要載入Debug版本的指令碼，則指令檔名將自動添加一個“debug”部分，例如“myjs.js”將自動變為“myjs.debug.js”。（顯得有些怪異，預先約定太多了，或許不是一件好事）
6. ScriptPath：這個屬性讓我非常鬱悶！官方的解釋是“作為所有指令檔的根目錄（全域路徑）”。按照我現在的理解，該屬性旨在方便地替換掉現有的某個版本的指令碼，而不必在每個<asp:ScriptReference>中逐一更改。當我們設定了該屬性之後，比如設定為“~/dflying”，則用戶端指令碼的引用方式就會變成“<script src="~dflying/Microsoft.Web.Extensions/1.0.61025.0/Microsoft.Web.Resources.ScriptLibrary.MicrosoftAjax.debug.js" type="text/javascript"></script>”這樣的靜態指令碼引用，而不是預設的通過axd資源得到，格式為“ScriptPath+程式集名+版本號碼+指令檔名”。這樣如果我們對架構內建的某個指令碼進行了修改，則可以使用這種方法將修改後的新版本JavaScript檔案引入到程式中，而且，這種靜態檔案的引用方法還不知不覺地提高了程式的執行效率。
7. OnAsyncPostBackError：指定AsyncPostBackError事件的伺服器端處理函數，在該處理函數中我們可以得到引發的異常，並根據不同的異常設定不同的AsyncPostBackErrorMessage，給使用者足夠友好的提示。
8. OnResolveScriptReference：指定ResolveScriptReference事件的伺服器端處理函數，在該處理函數中我們可以修改某一條指令碼的相關資訊，例如路徑，名稱，版本（Debug或者Release）等。

 

接下來讓我們看看<asp:ScriptManager>標籤中的各種子標籤的變化：

<ErrorTemplate>標籤

整個刪除。因為有了AsyncPostBackErrorMessage屬性、OnAsyncPostBackError事件以及用戶端Web Form架構，所以我們開發人員可以極其靈活地完全定製異常的顯示介面，而不用局限在原有的<ErrorTemplate>中。

ASP.NET AJAX中預設的非同步更新異常的顯示介面就是一個簡單的JavaScript alert()對話方塊。

<asp:ScriptReference>標籤

<asp:ScriptReference>標籤包含在<Scripts>標籤中，用來為頁面引入一個用戶端JavaScript指令碼。如果程式中需要使用Microsoft ASP.NET AJAX CTP Beta中的附加指令碼，或是我們自己編寫的自訂指令碼，則應該使用該標籤引入。<asp:ScriptReference>標籤中移除了ScriptName枚舉的支援，目前支援如下屬性

1. Assembly：要引用的指令碼所嵌入的程式集。
2. Name：嵌入到程式集中的某個指令碼的資源名稱。以上兩個屬性通常成對使用，例如：<asp:ScriptReference Name="Microsoft.Web.Resources.ScriptLibrary.PreviewGlitz.js"  Assembly="Microsoft.Web.Preview" />，就引入了Microsoft.Web.Preview.dll中的名為Microsoft.Web.Resources.ScriptLibrary.PreviewGlitz.js的JavaScript資源。
3. Path：通過路徑指定將要引用的自訂指令檔。
4. ScriptMode：作用同<asp:ScriptManager>標籤中同名屬性的定義，並將覆蓋其中的設定。同樣需要注意的是，若該屬性設定為Debug或程式實際運行時被認為需要載入Debug版本的指令碼，則指令檔名將自動添加一個“debug”部分，例如“myjs.js”將自動變為“myjs.debug.js”。
5. IgnoreScriptPath：是否忽略掉<asp:ScriptManager>標籤中ScriptPath屬性的定義。

 

<asp:ServiceReference>標籤

移除了GenerateProxy、OnScriptLoad和Type這三個雞肋屬性。留下的只有如下兩個：

1. InlineScript：是否將這個Proxy內聯到頁面中，內聯到頁面中將省去一次HTTP串連，某種程度上將略微加快程式的初始化速度。
2. Path：Web Service的檔案路徑。

 

<AuthenticationService>標籤

1. Path：驗證服務的檔案路徑。

 

<ProfileService>標籤

1. Path：使用者個人化服務的檔案路徑。
2. LoadProperties：將內聯到頁面中的使用者個人化屬性。

對於<AuthenticationService>和<ProfileService>標籤，似乎分別和AuthenticationServiceManager、ProfileServiceManager有關，同樣將用於用戶端Web Form模型中……今晚沒有足夠時間就不再深入研究了。問題：這兩個東西到底怎麼用？朋友們如果瞭解的話也請告訴我。

 

後記

時間倉促，行文有些草率，並沒有過多潤色，自然很多地方將會比較難懂，還請各位朋友海涵！由於我也是從頭再來開始接觸，一定會有很多錯誤之處，也請各位不吝批評指教，或者討論分享心得！

感謝大家對我的支援！