转载请注明出处:http://blog.csdn.net/z787326
Dojo 1.8中的 dojoConfig 对象(在1.7之前是djConfig)让我们可以配置Dojo的一些默认选项及行为。我们这一章讨论如何使用它来配置Dojo。
让我们用例子来看看在实际的程序中 dojoConfig 是如何工作的。
Hello Dojo!
√发现了吗,我们把 dojoconfig 的定义放在了dojo载入代码的前面,这是非常重要的,如果你反过来,把它放在后面。那么配置信息就会被忽略掉了。
在上面的例子中,我们设置了 parseOnLoad : false、has(dojo-firebug : true子属性)、async : true 这三个属性,和一个自定义的属性 foo:"bar"。我们在页面上放置一个模块,并在该模块的回调函数中,将 dojoConfig 的内容转化为JSON,并将dialog的内容设置为该JSON,而后你就在页面上看见了效果,但是你除了看见我们设置的属性之外,还有一些其他的属性,这是dojo默认加上的。
√还有很重要的一个问题就是你要区分上面代码中 dojoConfig 和 dojo/_base/config 之间的区别,dojoConfig 我们只是使用它将我们的参数传递给 dojo,仅仅只是传递而已,dojo/_base/config 则是将这些配置参数往程序里设置。
还有一种写法,就是在载入dojo的同时来设置dojoConfig,代码如下:
你现在知道了,我们可以在dojoConfig中给一些参数设置新的值,或者设置一些自定义参数,所以dojoConfig是dojo的一个通用配置属性包。接下来就让我们来看看其中有那些参数属性,我们改如何使用它们。
用has()这种模式来做功能特性支持是在dojo1.7时加入的一项非常重要的功能。什么是功能特性支持呢?has()它包含了一个特性集,这个特性集用于指定dojo中的特性是否被支持。例如我们可以使用下面的代码来禁用dojo-amd-factory-scan:
在dojo1.7之前的版本中,你可能习惯了使用isDebug属性来开启调试信息,在dojo1.7和1.8当中,如果你使用低版本的IE浏览器,想要使用Firebug来进行调试的话,我们可以通过设置dojo-firebug这个属性来实现,如果你有Firebug或者其他的控制台可以使用的话,那么它什么也不会做,反之,如果你没有一个可用的控制台,那么它将会加载dojo版的精简Firebug,并在页面的底部将控制台显示出来。这种模式使得我们在旧版本的IE和一些其他没有控制台的浏览器上可以方便地调试我们的dojo程序。
为了支持模块的AMD,dojo1.7中引入了新的加载程序,这个加载程序新增了一些配置选项,这些选项都十分的重要,包括如何定义一个包,如何起别名等等。下面我们来看几个重要的参数选项。
baseUrl: "/js"
packages:一个提供包的名称和位置的对象数组packages: [{
name: "myapp",
location: "/js/myapp"
}]
aliases:给模块取一个别名aliases: [
// [别名, 真名]
["cookie", "dojo/cookie"]
]
paths:创建路径paths: {
"text":"./text"
}
//使用packagePaths简写:
packagePaths:{
"path/to/some/place":[
"package1",
{
name:"package2",
main:"base"
}
]
}
//等价于:
packages:[{
name:"package1",
location:"path/to/some/place/package1"
},{
name:"package2",
location:"path/to/some/place/package2"
}]
async: true
parseOnLoad: true
√官方是建议将parseOnLoad的值设为false,它的默认值就是false,所以你也可以简单地忽略它。由开发人员显示的请求dojo/parse,并调用parser.parse()。
deps: ["dojo/parser"]
waitSeconds: 5
现在让我们用一个例子,将刚才提到的参数实际运用一下,一个很常见的情况,我们使用的dojo是从CDN获取的,同事我们使用的模块却在本地。