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的实现，现在我们可