从Atlas到Microsoft ASP.NET AJAX（4） - Browser Compatibility, Building Debug and Release Scripts, Def...

Browser Compatibility

在CTP版本中使用为解决浏览器兼容问题提供了一个抽象层，将功能集中到了IE浏览器的使用方式上。在服务器端如果发现客户端使用的不是IE浏览器，则会立即添加一个额外的JavaScript引用。

在RTM版本中，这一抽象层依旧存在，但是它基于了标准，也改进了其设计。因此，服务器端的浏览器类型调查已经不需要。取而代之的是在客户端进行的浏览器功能检查，以及一些其它经过抽象的API。一些基于组件的API也会使用这些抽象，例如，之前谈到的事件模型使用了DomEvent.addHandler和DomEvent.removeHandler这两个基于标准的方法。请注意，事件的命名规则是使用了“click”而不是“onclick”，这些API的名字和组件或类型使用的命名规则保持了一致。

Comment　　阅读过《 Professional JavaScript for Web Developers》的朋友们会发现，ASP.NET 2.0 AJAX Extentions使用的浏览器事件兼容方法和这本书的做法非常的相似。另外，这本书也推荐了根据浏览器功能的检查来提供浏览器兼容功能，而不是判断浏览器的类型与版本，因为根据检查浏览器功能得到的结果更为准确，也有可能支持更多的，甚至未来的浏览器。而现在取消服务器端的检测的做法也是因为这个原因。
不过我需要承认，我在看到Atlas以前的AtlasCompact.js代码时觉得它非常的不错，它为非IE的的浏览器提供了IE功能，这样开发人员只需要简单地为IE进行开发就可以了。我依旧觉得这些代码还是很值得研究和使用的，毕竟它还被使用在Windows Live系列产品中。另外，它还能够被添加到任何单为IE浏览器开发的应用中，从而得到一定的平台兼容性，这是Microsoft ASP.NET AJAX的Compact层无法做到的。

Building Debug and Release Scripts

我们设计的情景使我们意识到需要为ASP.NET AJAX提供一个强大而稳定的工具支持。这样的工具需要有能够支持工具的debug脚本，另外，它还有能力为产品环境创建release脚本。

在CTP版本中，debug和release脚本几乎没有差别，仅仅是release得到了压缩，移除了不必要的空格而已。在RTM版本中，我们考虑为Debug脚本提供强大的工具支持和编程体验，因此现在的debug脚本里有：

对文档注释的支持。它们不仅为InteliSense服务，也提供了在“编译时”的检查，例如对于检查参数类型的检查。

就像之前所提到的，使用Error对象的扩展而得到的错误处理能力。

经过命名的函数。与匿名函数相比，debug脚本中的函数存在着伪命名，这样在调试时，就能获得额外的信息。例如查看callstack时能够准确地发现方法的调用顺序。

Comment　　如果对比Debug目录和Release目录下的脚本就能很明显地发现两者的区别。例如上面所说的最后一条，在Debug中函数定义的样子是类似“Function.createDelegate = function Function$createDelegate(instance, method){...}”，而在Release模式下则类似“Function.createDelegate =function(instance,method){...}”。向“Function$createDelegate”这样的信息在使用Debug脚本进行调试时就能在callstack中看到。个人认为，我们应该也遵守这种设计规范。
Doc Comments

如果您是开发组件开发人员，您现在可以在Debug脚本中提供您自定义类型的类型描述信息，它们的作用是为Visual Studio“Orcas”提供的IntelliSense和语句补充（这些功能不会在Visual Studio 2005中出现）功能所需的信息。另外，文档注释也提供了使用Client FX验证机制来进行“编译时”检查的支持。

文档注释提供了以下功能：

您可以在构造函数或者成员中定义注释。

您可以在属性的get/set方法，以及事件的add/remove方法中定义注释。

您可以在接口的构造函数中定义注释。

注释能够支持复杂类型的参数和返回值。

　　下面的示例展示了在RTM里文档注释的使用方式，这里以BorderBehavior的片断作为例子，如下：

Type.registerNamespace('Custom.UI');

Custom.UI.BorderBehavior
=

function
(element) {

//
/ <summary>A border behavior</summary>

//
/ <param name="element">Associated element</param>

Custom.UI.BorderBehavior.initializeBase(
this
, [element]);
}
Custom.UI.BorderBehavior.prototype
=
{
...
get_color:
function
() {

//
/ <summary>Color</summary>

//
/ <value type="String"/>

return

this
._color;
},
...
}

Defining Type Descriptors

在CTP版本中，您通过继承Compoenent类而实现了ICustomTypeDescriptorProvider接口，因此您会重写getDescriptor方法并返回一个TypeDescriptor对象，以此支持XML-Script的解析，例如binding。

下面的例子展示了在CTP版本中定义一个Button类的代码，请注意它使用closure的方式。如下：

Custom.Button
=

function
(associatedElement) {
Custom.Button.initializeBase(
this
, [associatedElement]);
..

this
.getDescriptor
=

function
() {

var
td
=
Sys.UI.Button.callBaseMethod(
this
, 'getDescriptor');

td.addProperty('command', String);
td.addProperty('argument', String);
td.addEvent('click',
true
);

return
td;
}
...
}

在RTM版本中类型描述符被去除了，原因如下：

XML-Script需要额外的脚本以及加载和处理的逻辑，因此会影响脚本的大小和运行的性能。而这种不必要的负担，更多情况下之会在使用服务器端控件创建富客户端行为时产生。

XML-Script是面向客户端的，使用声明方式编程的模型，这些内容只在Value-add包内提供。

所有通过XML-Script定义的行为都是通过Javascript创建的，使用它们本身无需对于XML-Script的处理。（当然，如果有了合适工具的支持，XML-Script的开发会相对容易一些。）

目前还没有合适的工具支持XML-Script开发，导致其对于开发人员来说相当的麻烦。

Comment　　对于前三条我不置可否，可能有其一定的道理，但是对于最后一条所说的理由实在让我不满。不满的原因并不是XML-Script被去除导致的（事实上也只是转移到了Value-Add包内），而是因为文档声称没有办法支持XML-Script开发，我也辛辛苦苦地编写过数百行的Schema供Visual Studio 2005使用，微软不可能做不到更好。
现在我只能期望在Orcas里能够有更好的支持。
以上这些功能，包括XML-Script，已经被放入了Value-add包内，可以继续配合RTM版本使用。因此您能够编写一个组件，并支持开发人员通过XML-Script使用它。为了支持这种能力，Value-add包内仍然包括了TypeDescriptor对象的使用，不过现在已经使用JSON来表示了。这样，RTM版本无需任何支持就能定义一个类型描述符了。

下面的示例展示了与之前类似的Button组件的开发方式，不过现在是使用RTM版本进行开发。如下：

Custom.UI.Button
=

function
(associatedElement) {
Sys.UI.Button.initializeBase(
this
, [associatedElement]);
}
Custom.UI.Button.prototype
=
{
...
}
Custom.UI.Button.descriptor
=
{
properties: [ {name: 'color', type: String } ],
methods: [ ... ],
events: [ {name:'click'}, ... ]
}

您可以为属性添加readOnly的描述，以此确保这个属性有一个默认值.如下：

MyControl.descriptor
=
{ properties: [{name:
"
title
"
, type: String, readOnly:
true
}] }

如果您需要引用一个DOM元素，则使用Sys.UI.DomElement作为类型。如下：

MyControl.descriptor
=
{ properties: [{name:
"...

"
, type: Sys.UI.DomElement }] }

类似地，如果一个组件定义了一些引用其它组件的属性（可能在制作一个组合表单），那么在TypeDescriptor里则应该表明对这个类型的引用。如下：

MyControl.descriptor
=
{ properties: [{name:
"...
"
, type: Custom.Button }] }

如果您使用了Value-add包内的XML-Script，您就能够为类型的名字对应一个tag。Value-add脚本会根据类型描述符处理其余所有的工作。