Build your Dojo-based Javascript Application and deployed via CDN

关注

原创最新推荐文章于 2026-06-21 12:05:48 发布 1.6k 阅读 AI 写同款· GEO 优化 ›

如何用Javascript解析HTML？问题的提出是我需要将另一个网页的某些内容解析出来并集成到当前正在处理的网页中。第一想法就是，使用dojo.xhrGet得到网页的内容，再使用某种Javascript Library来解析。我熟悉的dojo并没有这种库，查询了一下，jQuery也没有。后来发现jQuery的作者，鼎阅读详情

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的选项，可以通过文件\util\buildscripts\jslib\buildUtil.js里进一步研究。

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

release:  Optimizing (shrinksafe) file: ../../release/edward/dojo/../../../../edward/front/release/e
dward.js
release:  Files baked into this build:
 
dojo.js:
./jslib/dojoGuardStart.jsfrag
./../../dojo/_base/_loader/bootstrap.js
./../../dojo/_base/_loader/loader.js
./../../dojo/_base/_loader/hostenv_browser.js
./../../release/edward/dojo/_base/lang.js
./../../release/edward/dojo/_base/array.js
./../../release/edward/dojo/_base/declare.js
./../../release/edward/dojo/_base/connect.js

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

现在来看看build profile

build profile

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

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。下面我们来看一个例子：

   1: layers : [

   2:     {

   3:         name : "../dijit.js",

   4:         resourceName : "dijit.dijit",

   5:         discard : true,

   6:         dependencies : ["dijit.dijit"]

   7:     }, 

   8:     {

   9:         name : ../release/myApp.js",

  10:         resourceName : "myApp",

  11:         layerDependencies : ["../dijit.js"],

  12:         dependencies : [

  13:         "myApp.base"

  14:         ]

  15:     }

  16: ],

注意第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文件夹的内容拷贝一次。如果你只是借用dojo的构建系统来构建自己的工程，而并不使用任何dojo的功能，应该可以在保留dojo的文件夹结构的前提下，清除掉dojo，dijit,和dojox文件夹下的内容，以加快构建速度。此外，即使使用了dojo，但如果没有用到dojox的功能，也可以将这个文件夹删除掉。单是删除这个文件夹就会加快不少速度。

第二，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来指定模块搜索路径。

   1: dojo.registerModulePath("myApp", "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前不可以有空格。

收录于