扩展JavaScript的时候,千万要保留其原来的所有功能,因为不知道别人的代码是否会用到这些。而且一般来说,为了写出兼容更多JS框架的代码,最保险的方法就是用JS的原生功能。然而……
在这个问题上,这次ASP.NET AJAX RC栽跟头了。
不知道大家有没有看过ASP.NET AJAX Library RC对于JavaScript的扩展?在RC的扩展中增加了这么一些代码:
Date._jsParse = Date.parse;
...
Date.parse = function Date$parse(value, formats) {
...
}
上面的代码将Date.parse的原生实 现改成了Date._jsParse函数,而自己重新定义了一个Date.parse方法。这样做的话,把Number、Date、Boolean对象都 提供了比较统一的parse功能,并且能够支持各种Format并具有本地化功能,着实是不错的扩展。可惜就是因为改了JavaScript的原生功能, 让Google Ads这个被广泛运用的……玩意儿,就这么Break了。
这个问题可是直接涉及到广大人民群众的切身利益,严重影响了人民群众的感情。比如在ASP.NET AJAX论坛,就在抱怨这件事情(
[url]http://forums.asp.net/thread/1499508.aspx[/url]),不过有问题自然就有人会解决,例如Cyril(一看到这张脸就觉得眼熟,原来我当时的《
另一种Atlas Scripts Intellisense的方法以及对比与分析》就是引用了他Blog上的方法)提出了一种解决方案:
Date.__cyril_parse = Date.parse;
Date.parse = function(s){
try {
return Date.__cyril_parse(s);
} catch (e){
var d = Date._jsParse(s);
if (d) {
return d;
} else {
throw e;
}
}
}
只要引入上面这段代码即可。这是很容易想到 的做法,不过还真的没有比这更简单或更有效的解决方案了:把ASP.NET AJAX的Date.parse扩展再另存起来,再重新写一个Date.parse方法,首先尝试ASP.NET AJAX的扩展,如果失败(幸好如果用户按照原来的使用方式会造成失败),则调用JavaScript的原有功能。问题就这么被解决了,不是吗?
这次ASP.NET AJAX RC的错误很低级,还好只是RC,有问题还不怕。不过,这也不就是RC Release的目的吗?至少现在基本上可以肯定,ASP.NET AJAX正式版里的扩展不会再有这个错误了。
本文转自 jeffz 51CTO博客,原文链接:http://blog.51cto.com/jeffz/60374,如需转载请自行联系原作者