从Atlas到Microsoft ASP.NET AJAX（4） - Browser Compatibility

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的片断作为例子，如下：



Defining Type Descriptors

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

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

　　在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版本进行开发。如下：

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

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

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

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

本文转自 jeffz 51CTO博客，原文链接：http://blog.51cto.com/jeffz/59548，如需转载请自行联系原作者