拥抱变化——从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模型中……今晚没有足够时间就不再深入研究了。问题：这两个东西到底怎么用？朋友们如果了解的话也请告诉我。

 

后记

时间仓促，行文有些草率，并没有过多润色，自然很多地方将会比较难懂，还请各位朋友海涵！由于我也是从头再来开始接触，一定会有很多错误之处，也请各位不吝批评指教，或者讨论分享心得！

感谢大家对我的支持！