《案例精解企业级网络构建》赠书活动开始啦！　最新活动：“Web安全大家谈”有奖征文

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

2006-10-21 17:15:00

　标签：Microsoft AJAX ASP.NET Atlas　　　[推送到技术圈]

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脚本会根据类型描述符处理其余所有的工作。

本文出自 “赵劼” 博客，转载请与作者联系！

上一篇从Atlas到Microsoft ASP.NET AJAX（5） - High..　　下一篇从Atlas到Microsoft ASP.NET AJAX（3） - Clas..

类别：从Atlas到ASP.NET ┆ 技术圈() ┆ 阅读() ┆ 评论() ┆推送到技术圈 ┆返回首页

相关文章

文章评论

昵称：
验证码：		点击图片可刷新验证码　　博客过2级，无需填写验证码
内容：