代码改变世界

从Atlas到Microsoft ASP.NET AJAX(4) - Browser Compatibility, Building Debug and Release Scripts, Defining Type Descriptors

2006-10-21 17:15 by Jeffrey Zhao, ... 阅读, ... 评论, 收藏, 编辑
Browser Compatibility

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

在RTM版本中,这一抽象层依旧存在,但是它基于了标准,也改进了其设计。因此,服务器端的浏览器类型调查已经不需要。取而代之的是在客户端进行的浏览器功能检查,以及一些其它经过抽象的API。一些基于组件的API也会使用这些抽象,例如,之前谈到的事件模型使用了DomEvent.addHandlerDomEvent.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脚本会根据类型描述符处理其余所有的工作。

 
使用Live Messenger联系我