http://blog.lotus-scent.com/web%E6%8A%80%E6%9C%AF/javascript%E5%BC%80%E5%8F%91/dojo/build-your-dojo-based-javascript-application-and-deployed-via-cdn/113

build系统是dojo异于其它Javascript框架的显著特征之一。通过build你的Dojo-based Javascript应用程序，可以立即获得以下好处：

• Java使用一个类一个文件的组织方式，这种方式方便了开发期管理；发行时可以将class打包成package，又减少了发行时的对象个数（如果采用压缩话，还缩小了文件尺寸）。通过dojo的build系统，就可以将指定目录下的全部或者部分Javascript自动打包成一个javascript文件，称作layer。因此，在开发中也可以做到一个’类’一个文件，而不用担心布署问题。
• 在build过程中可以指定是否做极简化(minification）。通过极简化，不但缩小了javascript文件的尺寸，以加快传输速度，减小带宽费用，也加快了浏览器的解析速度。这是因为一方面小的文件尺寸解析起来更快，另一方面变量名的极简化也使得解析速度加快。

事实上，dojo的build系统不仅用来build基于dojo的应用程序，也可以用来build/deploy基于其它Javascript框架的应用。

DOJO BUILD系统概览

Dojo的build系统的主要工作是，从指定的build profile文件读取配置，特别是要build的target，自动分析文件之间的依赖，将逻辑上属于同一个layer，但物理上分散的文件整合到一个javascript文件中（根据profile的指示），再对这些layer文件做极简化。最后，它还将未处理的源文件拷贝到指定的输出文件夹，以防止万一出现功能模块无法在layer中找到的情况。此外还可以通过build系统指定加载器（普通加载和cross-domain加载），指定css的选择器实现等功能。

构建系统本身需要：

• dojo SDK包
• Java运行时环境
• build profile，一个javascript文件
• 待build的应用程序代码

构建系统本身位于dojo/util/buildscripts文件夹下。在windows下可以通过运行build.bat来试运行一下。它会立即输出。

因为没有指定任何选项，特别是没有指定build profile，所以build系统无法工作，打印出命令提示出来。

关于build的选项，可以通过文件utilbuildscriptsjslibbuildUtil.js里进一步研究。

指定profile后再次运行build，这次会有：

  
  

   
   
release: Optimizing (shrinksafe) file../..//edwarddojo/../../../../front.js
   
   
Files baked into this build:
   
   
js:
   
   

   
   
./jslibdojoGuardStartjsfrag
   
   
./../../_base_loaderbootstrapjs
   
   
loaderjs
   
   
hostenv_browserjs
   
   
langjs
   
   
arrayjs
   
   
declareconnectjs
  
  

输出的最后告诉我们生成了哪些layer文件，这些layer文件中又包含了哪些内容。最后，它告诉你此次构建花了多少时间，输出文件的位置在哪。

现在来看看build profile

BUILD PROFILE

build profile是驱动构建系统运行的脚本文件。这个文件定义了一个中dependencies的字面量对象。这里要注意它与其它语言的构建系统文档不一样的地方是，它是一个可以运行的Javascript文件，因此遵守Javascript语法。也即，在定义对象时，出现在’:'右边的要么是字符串常量，要么是已经定义且赋值的Javascript变量，比如logger.TRACE。如果你的本意是要使用一个字符串常量，但却忘记加上引号，那么这个字符串会被当成一个变量被求值！！

build profile的语法元素主要有三类：

构建指示

通常我们在最开始的地方放置构建指示。凡是在文件buildUtils.js中列出的那些选项，都可以写在这一段。你也可以不在这个文件中指定，而在调用build.bat时，通过命令行指定。尚不清楚如果在命令行和profile中都指定了同一个选项，何者优先级高。下面是一个例子：

dependencies ={
   
   
 //stripConsole : 'all',
   
   
 loader  'xdomain',
   
   
 copyTests false localeList 'en-us' layers [
   
   
{
   
   
},
   
   
],
   
   

   
   
 prefixes[
   
   
["dijit""../dijit"]
   
   
}
  
  

例子中，layers和prefixes为空，接下来研究这两项。

layers

layers用来告诉构建系统要将哪些文件打包进哪些layer文件。由于可能有多个layer，因此layers实际上是一个由多个对象构成的数组。它的每个对象具有这样一些属性：

name，该layer的名字，它有两层意思。其一，它是要生的layer文件的文件路径和文件名。其二，在profile中用来引用这一layer对象的标识符。注意dojo的官方文档中长期一来存在着一个错误，即文档中它通过resourceName(后面将要讲到）来引用一个layer，而实际上这种说法是错误的。这一点，可以从dojo自己提供的example profile中得到验证（参见standard.profile.js中layerDependencies的引用）。基于第一层意思，因此我们可以将其指定到任何可以访问到的位置。

resourceName，这个名字是我们在dojo.provide和dojo.require中要使用的名字。

discard，取值为true或者false（不带引号）。它的作用是当与layerDependencies结合时，可以从build输出中排除掉某些javascript及其生成文件。比如如果mylayer.js使用到了dijit中的很多文件，但由于我们将要采用CDN方式来布署dojo工具包（后面再讲CDN方式布署dojo），所以并不需要自己构建的dijit，更不需要将这些dijit包含到mylayer.js中来。这时就要先定义dijit layer，再将dijit layer的discard属性定义为true。

dependencies：要将哪些javascript文件整合进本layer。下面我们来看一个例子：

layers {
   
   
 name "../dijit.js" resourceName:"dijit.dijit" discardtrue dependencies]
   
   
{
   
   
"../release/myApp.js" resourcename "myApp" layerDependencies  dependencies [
   
   
"myApp.base"
   
   
]
   
   
}
   
   
 注意第4行的resource name和第6行的dependencies。如果稍微有一点confuse的话，要记住在dijit文件夹下，实际上是存在一个叫做dijit.js的文件，它包含了大部分常用的dijit部件。这里也给出了一个提示，即如果你要将很多很多Javascript文件整合进一个layer文件，并不需要将其全部加入到profile中，也可以采用在另一个javascript文件中包含这些文件，再在profile中只引入这个总的包含文件即可，这样做的好处是减小了profile的大小。dojo的构建系统会根据dojo.require的提示来解析所有的依赖和传递依赖。注意，在dojo 1.6及未来的版本中，这个依赖除了由dojo.require定义之外，还可能由define函数来定义（define函数是dojo 1.6引进的关于AMD loader的实现的一部分）。这一点目前并未体现在其文档中。
 
 
 再看第11行，这一行提示构建系统，如果本layer有依赖到dijit.dijit里定义的resource，这些resource本身已通过layer “../dijit.js”加载，所以无需包含在本layer中。这一声明对减小myApp.js这一layer的大小是很重要的。
 
 
 最后，请注意在resourceName和dependencies中定义的那些字符串，都是点分隔的。其中在点前面的部分被称作前缀。构建系统通过前缀（prefix）来寻找构建的源文件位置。
 
 
 PREFIX 
   
   

    
    
PREFIXES [
    
    
// THE SYSTEM KNOWS WHERE TO FIND THE "DOJO/" DIRECTORY,BUT
    
    
// WE NEED TO TELL IT ABOUT EVERYTHING ELSE. DIRECTORIES LISTED HERE
    
    
// ARE,AT A MINIMUM COPIED TO THE BUILD DIRECTORY
    
    
"MYAPP""../MYAPP/SRC""DIJIT""../DIJIT"]
    
    
]
   
   
 
 第5行定义了MYAPP的源文件位置。因此前面LAYER定义中，MYAPP.BASE所指向的文件BASE.JS将从/MYAPP/SRC文件夹下寻找。
 
 注意构建系统只知道DOJO的位置，并不知道DOJOX和DIJIT的位置，因此这里也必须为它们指定路径。
 
 
 
 构建系统的优化
 
 
 在我的机器上，一个空白的dojo工程（即基本上没有自定义的模块源文件）构建最长可以花到4～5分钟。这要归功于dojo有很多很多小文件，以及构建时先要删除前面构建的文件，然后再将整个dojo文件夹的内容拷贝一次，这样做不仅速度慢，而且造成文件系统碎片化，最终降低了开发效率。如果是使用CDN部署的话，完全没有必要去构建dojo自已，只需要构建用户模块就好。即使是使用自己的站点来host dojo，也只应该在release前的那个build才构建dojo，在开发中，由于调试的需要，开发人员常常会使用SDK版的dojo。
 
 
 dojo的构建系统没有提供额外的参数来支持这一点(通过指定buildLayers可以使得‘action=release’时构建系统完全不做清理但这很可能也并不是我们想要的。如果我们在代码管理过程中删除掉了一个源文件，我们也希望它能从发行版中被删除掉），我们需要自己动手来修改build系统。
 
 
 打开utilbuildscriptsbuild.js文件，找到_copyToRelease函数，在其开始处加下这样的语句：
 
 
  
  

   
   
if(!kwArgscopyDojo &&;prefixName =="dojo"||
   
   
 prefixName "dijit"||
   
   
"dojox")){
   
   

   
   
 loggerinfo+" not copied due to your settings: copyDojo == flase");
   
   
return;
   
   
}
   
   
}
  
  
 
 
 这样，通过在profile里指定copyDojo:false，我们就可以禁止构建系统拷贝数量庞大的dojoSDK文件。但是，如果调用clean（action=clean），则所有的dojo文件会被从releaseDir中删除掉，这又会引起后面的build失败，所以我们还要对clean做些手脚。
 
 
function clean(){
   
   
("Deleting: " kwArgsreleaseDir);
   
   
// fileUtil.deleteFile(kwArgs.releaseDir);
   
   
copyDojo){
   
   
 fileUtildeleteFile"dojo"]);
   
   
}else{
   
   
[]);
   
   
}
   
   
}
  
  

我们为函数deleteFile增加了一个参数，接下来修改这个函数，在fileUtil.js文件中：

fileUtildeleteFile function(/*String*/fileName/*Array*/excludeFolders){
   
   
//summary: deletes a file or directory if it exists.
   
   
(typeof excludeFolders 'undefined'){
   
   
[];
   
   
var file new javaio.File);
   
   
iffileexists()){
   
   
isDirectory()){
   
   
for i  0lt excludeFolderslength i++){
   
   
 len [i].;
   
   
toString().slice(-len]){
   
   
fileName " is not deleted due to it's founded in excludeFolders.";
   
   
}
   
   
 files listFiles();
   
   
for files++){
   
   
thisfiles);
   
   
}
   
   
}
   
   
"delete"]();
   
   
}
   
   
}
  
  

这个函数里出现了java.io.File，这是由运行时Rhino支持的。这样使得Javascript有能力操作本地资源。

现在，可以在profile里指定action=’clean,release’，从而使得每次构建都得到更新的customer module，而不会引起dojo系统的重复拷贝（但是仍然会有一些其它动作跟dojo相关）。

第二，dojo允许指定构建的layer。在开发过程中可以将这个参数写在profile中。即使是指定了只构建custom layer，构建系统还是会拷贝dojo的文件—似乎省略的只是整合成layer及minify的过程。

部署的优化

dojo有一个激动人心的特性，就是它的加载器允许xDomain加载。简单地说，dojo的普通加载器使用了xhrGet来加载javascript脚本，再通过eval之类的方式激活javascript中的对象，或者调用document.write，将其写入文档，由浏览器来解析生成对象。普通加载器是默认的加载器，但它有一些问题。其一是，它无法利用浏览器多线程下载文件的能力；其二是不允许(xhrGet不允许）跨域加载脚本；其三是，在文档加载完成以后，它无法加载新的脚本，因为此时document.write不可用。尽管从安全角度看，浏览器禁止xhrGet跨域访问数据有其理由，但跨域加载脚本却有着绝对合理的理由。脚本文件都是静态文件，为了性能优化的考虑，大型网站常常使用专门的服务器和域名来host这些文件。比如一个网站可能使用myapp.example.com来host应用程序，而使用images.static.example.com和js.static.example.com来host这些静态文件。进一步地，为了在全球都能得到同样快速的服务响应，大型网站可能使用CDN来host这些文件，这样也使得javascript文件可能不跟应用程序文件在同一服务器上。

xDomain的加载方式解决了上述问题，更重要地是，它使用利用CDN加载成为可能。xDomain的加载方式是在文档的DOM模型构建完成之后，向DOM的文件头（head和body此时可以）插入<script>标签，这样触发浏览器自己去加载该资源。xDomain加载器需要自己照管的，就是文件依赖的解决，以及在所有资源可用之后，再调用用户指定的回调函数，从而启动用户的应用。

如果要构建一个支持xdomain加载的应用，需要在命令行或者profile中指定’loader：xdomain’属性。这样构建出来的layer文件，以及未被包入layer的文件，会多一个.xd的后缀。比如myApp.js支持xdomain加载时，构建的输出就是myApp.xd.js。当然，这两个文件的内容也是不同的。后者多了对xdomain加载的支持。

在部署的应用程序中使用xdomain加载有两种方式，一种是直接引用带.xd的dojo.xd.js；另一种是通过dojoConfig来指定。这样会导致dojo加载器自动寻找文件的xd版本。比如在使用xdomain加载的情况下，dojo.require(“myApp.base “)会导致加载文件myApp/base.xd.js。

加载器只知道在dojo.xd.js所在的目录，以及这一目录同级的目录中支寻找javascript模块。在使用CDN的情况下，显然此时加载器无法寻找到用户自定义的、部署在自己domain内的机器上的模块。此时需要通过dojoConfig的modulePaths或者registerModulePath来指定模块搜索路径。

registerModulePath"http://www.example.com/myApp");
  
  

dojo文档里没有提到在使用CDN进行下如何指定这个路径，它的示例都采用相对路径。不过实验证明可以如上例所示使用绝对路径。注意，dojo文档里提到，这个路径绝对不能以’/'结尾，因为dojo会自己（不加判断地）附加一个上去。

最后要注意，当使用CDN部署和xdomain加载时，你的自定义模块也应该是xd的。而如果你使用非xd的dojo来加载部署在其它机器上的模块是，你多半会得到浏览器抛出的不能跨域访问的错误—因为dojo在底层使用了xhrGet（不知道dojo 1.7全面采用AMD加载后，这一实现是否被改写）。

另一个常见，但却是false alarm的case是，在使用xdomain加载的情况下，如果使用dojo来声明一个类，但是关于其路径，provide和declare等不对应，此时会出现文件加载成功（已经写入到HTML文件中的头部），但抛出cann’t load xdomain resource错误。这个与xdomain关系不大了，应该仔细看看javascript的写法。

FAQ

Q: 在profile中将log级别设置为log : ‘logger.TRACE’，但却没有任何输出？

A：默认地build系统的日志级别就是最详细一级。注意profile是Javascript，所以问题中的赋值实际上是给log设定了一个字符串变量，而util/buildScripts/jslib/logger.js期待一个整数值，logger.TRACE是它的一个常量。其它取值是logger.INFO,logger.WARN,logger.ERROR。

Q：在一次构建中，假设target是layer.js。已指定是xdomain构建，但仅生成layer.js，没有生成layer.xd.js？

A：如果在profile中指定了layerDependencise,就会出现这样的情况。但遗憾地是，屏幕输出仍会令人困惑地打印出已生成layer.xd.js文件。

Q: 如果要一次build多个layer，应该如何指定？

A：buildLayers: ‘tests/tests.js,edward/edward.js’ 使用逗号分隔，未经验证，但最好不要在逗号后加上空格。

Q：为什么测试文件在build中没有被生成？

A：如果指定了copyTests:false，或者mini:true都会出现这种情况。mini的缺省值为true。

Q：如何troubleshooting构建过程中出现的各种状况？

A：可以在util/buildscripts/build.js中添加调试日志。

Q: Issue of ‘ js: uncaught JavaScript runtime exception: TypeError: Cannot find function release in object [object global].’?

A: 请检查profile中action一项。可以写作action:”clean,release”，但release前不可以有空格。

Q: xDomain编译，加载dojo的某个模板文件时，HTTP显示为200 ok，无内容，Firefox报错NS_ERROR…

A: cross domain加载时，不可以以html的方式加载模板，这些模板必须插入到使用它们的js文件中去。即internString=true

Q: Error: coud not load cross domain resources:dojo.nls._xx?

A: Dojo build system has this bug and it’s notthoroughlyfixed. Please refer tohttp://bugs.dojotoolkit.org/ticket/5225. According to the tracker,it’s caused by using “../” as a prefix of a layer name,and try build with I18N feature. The solution is remove “../” from the layer name.