Dojo 1.8：向完美架构继续前行
Dojo 1.8已正式发布数星期，作为Dojo的铁杆粉却直到今天才来总结，实在心有不安，但这并不妨碍我们来看一看那些让人眼前一亮的新特性。作为历史最悠久的RIA框架，Dojo的发展一直不冷不热。比起后来者JQuery的大红大紫，Dojo则默默的按照自己的步伐坚定的前行着。而对完美架构的追求，则构成了Dojo前行的主旋律，这也使得Dojo一直拥有一批坚定的支持者。
Dojo显然并不重视设计灵巧的API，但却非常看重编程思想的应用，以及对前端架构的研究。我们现在就来看看Dojo 1.8是如何在这个方向上继续努力着。
1. 对匿名模块的彻底支持：dojo/parser支持了对模块ID的解析
从上个1.7版本开始，Dojo全面引入了AMD（Asynchronous Module Definition）的机制。这使得每个模块的逻辑都完全拥有自己的闭包，通过返回值来暴露API接口或者数据。这样的模块是完全匿名的，AMD Loader会根据模块ID（例如：dojo/html）来映射到路径去寻找对应的文件。比起旧的Loader中每个模块都需要声明dojo.provide('dojo.html')，AMD机制真正做到了DRY原则（Don't Repeat Yourself），模块路径就是唯一标识符，不再需要在模块内部重复指定自身路径。这样的架构也让Dojo几乎可以做到完全没有全局变量的存在，说几乎是因为1.8之前有一个例外：通过Html声明方式创建的widget仍然需要一个全局的data-dojo-type属性：
<input type="text" data-dojo-type="dijit.form.TextBox"/>
这里的dijit.form.TextBox就是一个全局变量，表示一个TextBox控件的类名。在原来的dijit/form/TextBox模块中，必须有一个定义：
declare('dijit.form.TextBox', [], {});
dojo的parser会根据这个Widget的data-dojo-type去找对应的实现类。所以，尽管作为AMD模块已经是匿名，但其却有一个隐藏的全局变量在模块内定义，导致其自身其实并不是真正意义上的匿名，即不是完全的DRY。
然而在1.8中，这最后一个局限也完全消失了。dojo/parser能够根据模块ID来找到TextBox的实现，现在我们可以这样声明一个Widget：
<input type="text" data-dojo-type="dijit/form/TextBox"/>
尽管表面上看来，只是把点（.）换成了斜杠（/），但从编程的思想上来看，则可以让模块减少了一个概念：一个Widget就只有一个标识，就是模块ID。而不是之前既有模块ID，又有Widget类名这样容易混淆的情形。概念上的简单和清晰是理解易维护的重要前提。
本质上来看，AMD取代传统的dojo.require无关乎性能，仅关乎于架构。AMD能让你沿着正确的路线开发松耦合的模块，让应用更加容易理解和维护。而Dojo正在不断的完善着细节，帮助我们设计出更好的应用架构。
2. 让每个Widget都有插件机制：新的data-dojo-mixins属性
插件机制是建立灵活可扩展应用的一个最佳实践，而现在Dojo通过这个全新的属性全面实现了插件机制，让Dojo的Widget在使用时可以灵活决定自己需要的特性。因为这个属性的存在，Widget的开发也将可以更加模块化，每一组功能都能独自定义。在使用的时候，根据具体的使用场景，来决定是否启用此功能。比如，在dojox中提供了最近较为流行的TreeMap组件。模块dojox/treemap/TreeMap本身仅仅包含了最基础的功能。而对于键盘支持，色块拆分等功能则通过可插拔的模块来实现：dojox/treemap/Keyboard和dojox/treemap/DrillDownUp模块。这样的附属模块可以理解为插件，按照需要将其添加到data-dojo-mixins属性中即可开启相应的功能。
<div data-dojo-type="dojox/treemap/TreeMap" data-dojo-mixins="dojox/treemap/Keyboard, dojox/treemap/DrillDownUp"></div>
在这里，data-dojo-mixins属性中用逗号隔开的模块就可以看成一个个插件。不仅新控件可以利用插件机制，为现有组件添加新的功能，也可以通过提供插件来实现。比起派生一个新类来实现此功能，插件是可以通用的。例如：假设要为dijit/form下的TextBox，Select等表单控件添加语音识别的功能，可能只需要写一个my/voice/Recognizer模块，这样具有set('value', value)这样接口的Widget都将能灵活选用这个组件，而不需要为每个Widget都派生一个新的类。而对于多个插件的功能组合，则更显然data-dojo-mixins会非常合适。
现在看到的是声明方式创建的Widget我们可以很好的利用data-dojo-mixins实现插件机制。那么对于动态创建的Widget呢？其实这1.8之前已经可以实现：
var treemap = new (declare(['dojox/treemap/TreeMap', 'dojox/treemap/Keyboard', 'dojox/treemap/DrillDownUp']))(arguments);
模块的灵活性，一直是Dojo的重点关注。从引入AMD开始，Dojo就提出了base-less的概念，即Dojo框架可以配置为没有任何核心库，所有的模块都按需加载。这要求每个模块提供的功能独立而精简，从而能够实现最终仅仅加载需要的代码的目的。而data-dojo-mixins属性则是可以帮助我们将功能拆分并模块化到极致。这在目前JavaScript代码普遍臃肿的大环境下无疑是一个让人眼前一亮的概念和做法。
3. 契约式编程：dojo/promise
契约式编程是另一种很好的编程实践，它的目标是让程序的各个模块各司其职，仅仅关注自己需要完成的事情，而不用去关心其它模块该关心的事情。从而可以降低模块之间的耦合度，同时也让程序在语义上更加容易理解。其概念已经非常成熟，读者可以搜索相关资料，这里不再赘述。
虽然在1.8之前，Dojo可以通过dojo.Deffered实现契约编程的思想，但是终归不是很正式。而从1.8起，Dojo提供了正式的类和API来全面支持契约式编程：
dojo/promise/Promise - 契约核心类，所有实现契约机制的类都能够提供一个Promise类的实例。比如dojo/Deffered，专门对应于异步的情形。
dojo/errors/CancelError - 当一个契约被未知原因的取消时，提供此默认错误。
dojo/promise/all - 接受多个契约作为参数，返回一个新的契约。只有当多个契约都得到满足时，新契约才会得到满足。从本质看，这取代了原来的dojo/DeferredList。
dojo/promise/first - 接受多个契约作为参数，返回一个新的契约。只要其中一个契约得到满足时，新契约立刻满足。
举例：
require(["dojo/promise/all", "dojo/Deferred", "dojo/dom", "dojo/on", "dojo/json", "dojo/domReady!"],
function(all, Deferred, dom, on, JSON){
function googleRequest(){
var deferred = new Deferred();
setTimeout(function(){
deferred.resolve("foo");
}, 500);
return deferred.promise;
}
function bingRequest(){
var deferred = new Deferred();
setTimeout(function(){
deferred.resolve("bar");
}, 750);
return deferred.promise;
}
function baiduRequest(){
var deferred = new Deferred();
setTimeout(function(){
deferred.resolve("baz");
}, 1000);
return deferred.promise;
}
on(dom.byId("startButton"), "click", function(){
dom.byId("output").innerHTML = "Running...";
all([googleRequest(), bingRequest(), baiduRequest()]).then(function(results){
dom.byId("output").innerHTML = JSON.stringify(results);
});
});
});
通过这段代码可以看到，对每个搜索引擎的搜索请求都返回一个契约，外界程序只需关心这个契约。在搜索完成之后，契约会通过调用resolve方法来告诉外界自己已完成任务。从而外界仅需要关心什么时候开始搜索，以及搜索完成后自己该做什么。其逻辑和语义都非常清楚和合理。通过promise提供的all，first方法，外界可以更灵活的对契约进行管理。
通过promise，请求发起和结果处理过程被严格的区分开来，你将不得不分开代码处理逻辑，这种隐含的硬性规定让代码程序结构更加良好，代价是会让初用者觉得上手困难，但是一旦习惯，带来的好处将是一劳永逸的。
4. 更为统一的IO模块：dojo/request
所有的RIA框架都会通过隐藏底层细节，提供统一的一致的API来实现跨浏览器的支持。而现在Dojo正在将跨浏览器扩展到跨JavaScript环境。dojo/request正是有这样需求的一个API。在浏览器端，通过XMLHttpRequest获取数据，而在NodeJs之类JavaScript环境则用NodeJS提供的文件系统API来实现。
dojo/request这个package引入了一种用于异步请求的全新架构。这个模块将用户从具体的请求细节中抽象出来，也就是说，用户无需关心请求是如何发生的。dojo/request正是基于上文提到的dojo/promise来构建的。当引入dojo/request模块时，将根据运行平台自动返回对应的实现。比如，浏览器中就会使用dojo/request/xhr，而NodeJS平台则会使用dojo/request/node。
下面的代码演示了dojo/request的基本用法：
require(["dojo/request"], function(request){
var promise = request(url, options);
promise.then(
function(data){
},
function(error){
}
);
promise.response.then(
function(response){
},
function(error){
}
);
request.get(url, options).then(...);
request.post(url, options).then(...);
request.put(url, options).then(...);
request.del(url, options).then(...);
});
详细的dojo/request的介绍大家可以参考Dojo中文博客的文章：深入浅出dojo/request: http://blog.csdn.net/dojotoolkit/article/details/7991286
5. 面向移动设备的全面支持：dojo/touch，dojox/mobile
dojo/touch模块的目的是为了让面向PC的Web应用也能够运行在移动设备上，它提供了许多键盘鼠标事件和手势操作的映射。从而让普通的控件在移动设备上也能正常工作。现在Dojo自带的控件基本都采用了dojo/touch来实现对移动设备的支持。对于自定义的控件，也可以通过dojo/touch模块来实现这一功能。
Mobile是最近的热点领域，HTML5能够让同一份代码运行在不同的平台上。虽然有些类型的应用并不适合使用HTML5，但大多数信息展示和简单交互的移动应用非常适合使用HTML5，能够大大减少开发维护成本。而Dojo 1.8在对Mobile设备提供了大力的支持，提供了多达28个全新的控件，比如TreeView，ScrollablePane，DatePicker，GridLayout等常用控件。通过PhoneGap+Dojo把HTML5封装成手机应用，将是一个完全免费的开源跨平台移动开发解决方案。这也正是IBM使用的解决方案。
小结
Dojo一直非常看重编程思想的使用，以及前端架构的优化。比如1.8中的契约式编程，AMD增强，等等。虽然提供了大量新的API，但是为了保证向后兼容仍然保留了原有的API，只是会标识为已过期。这些过期的API将会在明年发布的2.0版本中彻底删除。这在一定程度增加了升级的难度，但是为了软件的健壮和可维护性，这是值得付出的代价。1.8和1.9版本也使得到2.0的过渡更加平滑。总体来说，我相信随着大家对Dojo的深入了解，Dojo一定会出现在越来越多的大型项目之中。
参考资源：
Dojo 1.8 下载：http://dojotoolkit.org
Dojo 1.8 Release Notes: http://dojotoolkit.org/reference-guide/1.8/releasenotes/1.8.html
Dojo中文博客：http://blog.csdn.net/dojotoolkit
Dojo新浪微博：http://weibo.com/dojotoolkit
本文首发于infoQ，原文链接：http://www.infoq.com/cn/articles/dojo-1.8