拥抱变化——从Atlas到ASP.NET AJAX（2）：变化得翻天覆地的ScriptManager

最新推荐文章于 2024-11-05 21:37:11 发布

sun00wen00sheng

最新推荐文章于 2024-11-05 21:37:11 发布

阅读量1.3k

点赞数

分类专栏： Ajax 文章标签： asp.net ajax microsoft 脚本 javascript asp

Ajax 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

阅读本文之前，您需要安装完成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的不足：

MicrosoftAjax.js 67KB
MicrosoftAjaxRuntime.js 15KB
MicrosoftAjaxWebForms.js 32KB
PreviewDragDrop 42KB
PreviewGlitz.js 14KB
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>标签所支持的属性：

AllowCustomError：在异步更新发生异常时是否使用Web.config中<customErrors>这一节的设定。<customErrors>中可以指定应用程序级别的错误处理页面，如果我们比较懒，则可以设定该属性为true，让发生异常后和普通ASP.NET程序一样重定向至某个专门显示错误的页面。一般来讲，最好设置其为false，因为这是Ajax程序，页面跳转是我们应该竭力避免的。
AsyncPostBackErrorMessage：异步更新发生异常时发送给客户端的错误信息，可以在AsyncPostBackError事件的处理函数中根据异常的不同而动态设定该信息。然后客户端Web Form框架就可以格式化并显示给用户，这也是我推荐的Ajax异常处理方式。
AsyncPostBackTimeout：异步更新的超时时限，单位为秒，默认值为90。没啥多说的，没事就别改了。
EnablePartialRendering：（终于看到一个在Atlas中曾经有的属性了，好激动……）是否支持页面局部更新，默认值改为true，这样在用UpdatePanel的时候就不必每次都要留意设置ScriptManager的该属性了，不过也自然地带来了效率上的轻微影响。究竟何种方式最好，也是谓仁者见仁，智者见智的问题。
ScriptMode：指定使用客户端脚本的版本（Debug或者Release），该属性的设置结果同样受制于配置文件中retail相关设置，详请参考http://ajax.asp.net/docs/mref/332fcb41-e4ab-4c1f-bb5e-61b49035af74.aspx 。需要注意的是对于自定义脚本，若该属性设置为Debug或程序实际运行时被认为需要加载Debug版本的脚本，则脚本文件名将自动添加一个“debug”部分，例如“myjs.js”将自动变为“myjs.debug.js”。（显得有些怪异，预先约定太多了，或许不是一件好事）
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文件引入到程序中，而且，这种静态文件的引用方法还不知不觉地提高了程序的执行效率。
OnAsyncPostBackError：指定AsyncPostBackError事件的服务器端处理函数，在该处理函数中我们可以得到引发的异常，并根据不同的异常设置不同的AsyncPostBackErrorMessage，给用户足够友好的提示。
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枚举的支持，目前支持如下属性

Assembly：要引用的脚本所嵌入的程序集。
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资源。
Path：通过路径指定将要引用的自定义脚本文件。
ScriptMode：作用同<asp:ScriptManager>标签中同名属性的定义，并将覆盖其中的设定。同样需要注意的是，若该属性设置为Debug或程序实际运行时被认为需要加载Debug版本的脚本，则脚本文件名将自动添加一个“debug”部分，例如“myjs.js”将自动变为“myjs.debug.js”。
IgnoreScriptPath：是否忽略掉<asp:ScriptManager>标签中ScriptPath属性的定义。

<asp:ServiceReference>标签

移除了GenerateProxy、OnScriptLoad和Type这三个鸡肋属性。留下的只有如下两个：

InlineScript：是否将这个Proxy内联到页面中，内联到页面中将省去一次HTTP连接，某种程度上将略微加快程序的初始化速度。
Path：Web Service的文件路径。

<AuthenticationService>标签

Path：验证服务的文件路径。

<ProfileService>标签

Path：用户个性化服务的文件路径。
LoadProperties：将内联到页面中的用户个性化属性。

对于<AuthenticationService>和<ProfileService>标签，似乎分别和AuthenticationServiceManager、ProfileServiceManager有关，同样将用于客户端Web Form模型中……今晚没有足够时间就不再深入研究了。问题：这两个东西到底怎么用？朋友们如果了解的话也请告诉我。

后记

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

感谢大家对我的支持！