Dojo 1.9在加载语言环境时构建'multipleDefine'错误

时间:2013-05-17 01:28:50

标签: dojo locale nls dojo-build dojo-1.9

我的dojo应用程序在构建之后中断,在加载应用程序时,抛出'multipleDefine'并给出此错误:

  

错误{src:“dojoLoader”,info:Object}

消息:multipleDefine

  

info:Object {pid:“dojo”,mid:“dojo / nls / dojo_en-us”,pack:Object,   url:“dojo / nls / dojo_en-us.js”,执行:5 ...}

这是我的个人资料:

var profile = {
// `basePath` is relative to the directory containing this profile file; in this case, it is being set to the
// src/ directory, which is the same place as the `baseUrl` directory in the loader configuration. (If you change
// this, you will also need to update run.js.)
basePath: '../src/',

// This is the directory within the release directory where built packages will be placed. The release directory
// itself is defined by `build.sh`. You should probably not use this; it is a legacy option dating back to Dojo
// 0.4.
// If you do use this, you will need to update build.sh, too.
// releaseName: '',

// Builds a new release.
action: 'release',

// Strips all comments and whitespace from CSS files and inlines @imports where possible.
//cssOptimize: 'comments',

// Excludes tests, demos, and original template files from being included in the built version.
mini: true,

// Uses Closure Compiler as the JavaScript minifier. This can also be set to "shrinksafe" to use ShrinkSafe,
// though ShrinkSafe is deprecated and not recommended.
// This option defaults to "" (no compression) if not provided.
optimize: '',

// We're building layers, so we need to set the minifier to use for those, too.
// This defaults to "shrinksafe" if not provided.
//layerOptimize: 'closure',
layerOptimize: '',

// Strips all calls to console functions within the code. You can also set this to "warn" to strip everything
// but console.error, and any other truthy value to strip everything but console.warn and console.error.
// This defaults to "normal" (strip all but warn and error) if not provided.
stripConsole: 'all',

// The default selector engine is not included by default in a dojo.js build in order to make mobile builds
// smaller. We add it back here to avoid that extra HTTP request. There is also a "lite" selector available; if
// you use that, you will need to set the `selectorEngine` property in `app/run.js`, too. (The "lite" engine is
// only suitable if you are not supporting IE7 and earlier.)
selectorEngine: 'acme',


//localeList:"en-gb,en-us,de-de,es-es,fr-fr,it-it,pt-br,ko-kr,zh-tw,zh-cn,ja-jp",

// Builds can be split into multiple different JavaScript files called "layers". This allows applications to
// defer loading large sections of code until they are actually required while still allowing multiple modules to
// be compiled into a single file.
layers: {
    // This is the main loader module. It is a little special because it is treated like an AMD module even though
    // it is actually just plain JavaScript. There is some extra magic in the build system specifically for this
    // module ID.
    'dojo/dojo': {
        // In addition to the loader `dojo/dojo` and the loader configuration file `app/run`, we are also including
        // the main application `app/main` and the `dojo/i18n` and `dojo/domReady` modules because, while they are
        // all conditional dependencies in `app/main`, we do not want to have to make extra HTTP requests for such
        // tiny files.
        include: [ 'dojo/i18n', 'dojo/domReady', 'app/main', 'app/run' ],

        // By default, the build system will try to include `dojo/main` in the built `dojo/dojo` layer, which adds
        // a bunch of stuff we do not want or need. We want the initial script load to be as small and quick to
        // load as possible, so we configure it as a custom, bootable base.
        boot: true,
        customBase: true
    },
},

// Providing hints to the build system allows code to be conditionally removed on a more granular level than
// simple module dependencies can allow. This is especially useful for creating tiny mobile builds.
// Keep in mind that dead code removal only happens in minifiers that support it! Currently, only Closure Compiler
// to the Dojo build system with dead code removal.
// A documented list of has-flags in use within the toolkit can be found at
// <http://dojotoolkit.org/reference-guide/dojo/has.html>.
staticHasFeatures: {
    // The trace & log APIs are used for debugging the loader, so we do not need them in the build.
    'dojo-trace-api': 0,
    'dojo-log-api': 0,

    // This causes normally private loader data to be exposed for debugging. In a release build, we do not need
    // that either.
    'dojo-publish-privates': 0,

    // This application is pure AMD, so get rid of the legacy loader.
    'dojo-sync-loader': 0,

    // `dojo-xhr-factory` relies on `dojo-sync-loader`, which we have removed.
    'dojo-xhr-factory': 0,

    // We are not loading tests in production, so we can get rid of some test sniffing code.
    'dojo-test-sniff': 0
}

}

这里是src /

里面的index.html
  

注意:build.sh负责删除“isDebug”标志   部署到生产。如果你完全修改这个标志,你会的   打破构建!

<script data-dojo-config="async: 1, tlmSiblingOfDojo: 0, locale:'en_US', isDebug: 1" src="dojo/dojo.js"></script>

<!-- Load the loader configuration script. Note that this module ID is hard-coded in build.sh in order to provide
     an optimised build that loads as few as one script for the entire application. If you change the name or
     location of this module, you will need to update build.sh too. -->
<script src="app/run.js"></script>

这是dist /

中生成的index.html
<!DOCTYPE html>
<html>
    <head>
        <meta charset="utf-8">
        <link rel="stylesheet" href="app/resources/app.css">
    </head>
    <body class="claro">
        <script data-dojo-config=
            "async: 1, tlmSiblingOfDojo: 0, locale:'en_US', deps:['app/run']" 
            src="dojo/dojo.js"></script>
    </body>
</html>

我检查确保dojo / nls / dojo_en-us.js存在且没问题。我在这一点上陷入困​​境,毫无头绪!

感谢您解决此问题的任何帮助。

3 个答案:

答案 0 :(得分:0)

您可以在 run.js 中发布您的要求吗? 你在那里需要“dojo / _base / config”吗?

[刚注意到同样的错误因为我忘记了;)]

来自文档的

  

重要的是要注意dojoConfig和dojo / _base / config之间的区别。 dojoConfig纯粹用于输入目的 - 这是我们将配置参数传递给加载器和模块的方式。在引导过程中,将从这些参数中填充dojo / _base / config,以便以后按模块代码进行查找。

答案 1 :(得分:0)

我遇到了类似的错误问题

  

multipleDefine

尝试将greensock库包含到我的dojo项目中时。

当dojo外部的另一个库声明自己的define函数(在我的情况下是TweenMax)时,会出现问题,因为它们与dojo loader发生冲突。

解决方案是确保在使用define函数的库或脚本加载后调用dojo加载程序。

所以dojo应该是你的脚本中最新加载的html head

<head>
    <script src="yourLibrary.js"></script>
    <script src="dojo/dojo.js"></script>
</head>

使用jQuery UI和其他库也可以看到此问题。

答案 2 :(得分:0)

在加载器文档中有一个关于此的说明(无论如何都是在此响应时)。

  

<强> multipleDefine
  AMD定义被称为引用具有的模块   已经定义了。这个问题最常见的原因是加载   模块通过HTML文档中的元素。使用装载机;   不要使用元素。第二个最常见的原因是过世   要定义的显式模块标识符;也不要这样做。

https://dojotoolkit.org/reference-guide/1.10/loader/amd.html

许多库现在都实现了UMD,它基本上会尝试自动检测AMD加载器的存在。例如,Bootstrap--流行的前端框架 - 实现了UMD。

因此以下示例将起作用(请注意,bootstrap将全局加载):

<script src="path/to/bootstrap.js"></script><!--UMD packaged library-->
<script src="path/to/dojo/dojo.js"></script><!--then dojo loader-->

但是下面的第二个例子不起作用,因为UMD代码将检测AMD加载器并使用它来注册自己。这将根据文档触发multipleDefine错误。

<script src="path/to/dojo/dojo.js"></script><!--dojo loader first-->
<script src="path/to/bootstrap.js"></script><!--then UMD library-->

如果要全局加载库,请使用上面的第一个示例并将其加载到dojo加载器中。如果要将库加载为AMD模块,请使用加载程序。