enhance loader to be AMD-compliant while keeping dojo.provide/require backcompat

[Rawld Gill]

This is a detailed description of the changes made to the v1.6- bootstrap and loader that move dojo to a fully AMD-capable and module system while maintaining backcompat with the dojo.provide/require module system.

Motivation and Goals

The purpose of this enhancement was to move from the dojo-proprietary loader API (dojo.provide, dojo.require et al) to the CommonJS ​Modules/AsynchronousDefinition (AMD) API. This resulted in the following benefits:

• Dojo modules are interoperable with other non-dojo-based systems
• Modules can be loaded asynchronously
• Owing to asynchronous loading, modules may be loaded by script injection; thereby improving the debugging environment
• Owing to asynchronous loading, many modules may be loaded concurrently, thereby improving loading performance
• Owing to asynchronous loading via script injection, there is no difference in loading algorithms when the modules reside "cross-domain", and therefore, the v1.6- synchronous and cross-domain loaders can be replaced by a single loader
• Owing to the AMD API, module namespaces can be sandboxed allowing several different versions of the same same module set or several different instances of the exact same module set to peacefully co-exist on a single web page. This capability of the AMD API completely eliminates the need for the so-called "multi-version" feature of dojo 1.6-.

Since the v1.6- bootstrap and loader are tightly integrated, it was impossible to replace the loader without heavily modifying the bootstrap. Consequently, the bootstrap was completely refactored as part of this enhancement. Each orthogonal feature set was divided into a separate module. This both decreased complexity and allowed for builds to optionally discard unused features. For example, dojo._Url and page unload detect are now optional features.

Coincident to this project, the has.js API was employed for feature detection as well as conditional code inclusion. In particular, the Dojo project is replacing build pragmas with has.js-bracketed code. This makes testing code branches easier and further decreases complexity by removing an extra-lingual construct (pragmas). The decision to add the has.js API as part of this project was made for the following reasons:

• the adopted asynchronous loader already included and required the has.js API
• the has.js API is part of the bootstrap which was already being heavily modified.

An overarching goal of this enhancement was to facilitate building optimized (in size) applications. As the mobile environment has become at least as important as the standard browser environment, optimizations for that environment are important. Where possible, features were added to enable optimizing for small, focused applications.

Finally, the enhancement maintains 100% backcompat with the 1.x dojo.provide/require API.

Overview of Changes

Broadly, the changes consequent to this enhancement included:

1. Importing the bdLoad AMD loader into dojo and adding a backcompat API that supports synchronous operation and the dojo v1.6- loader API.

2. Pulling the v1.6- bootstrap out of the 1.6- loader and reassembling it as a set of orthogonal modules.

3. Removing any dependencies on private v1.6 loader features throughout the code stack since these features would not exist with the new loader (e.g., some modules directly manipulated dojo._loaders, the dojo.addOnLoad queue).

4. Updating all the dojo unit tests to demonstrate the new system worked in both synchronous and asynchronous modes. dijit unit tests were intentionally left untouched to prove that "old code" would still work.

5. Modifying all the module define applications in dojo and dijit to utilize anonymous module identifiers and relative module identifiers in define/require dependency vectors.

6. Modifying DOH to be an AMD application to work with the browser, Rhino, and node.js.

7. Providing a new build program that can consume the new AMD module format, the has.js API, and execute several new kinds of build transforms necessary to realize the potential of the the new module system and bootstrap refactor (e.g., provide a build for release that includes absolute module identifiers in place of the anonymous format found in the repository. The new build program operates on both node.js and rhino, and provides a platform going forward.

8. Enhance the docscript program as required to consume the AMD module format.

Details of each of these items are discussed in separate sections below.

The Loader

bdLoad was donated by Altoviso LLC and imported into the dojo project.

The Bootstrap

The v1.6- sync-loader bootstrap evaluates the following modules (in the order given):

1. dojo.js
2. dojo/_base/_loader/bootstrap.js
3. dojo/_base/_loader/loader.js
4. dojo/_base/_loader/hostenv_browser.js
5. dojo/_base.js

Much of the non-loader functionality contained in the above modules has been moved to standard AMD modules as follows:

1. The browser-only part of dojo/_base.js moved to dojo/_base/browser.js
2. Configuration processing found in dojo.js and dojo/_base/_loader/bootstrap.js moved to dojo.js and dojo/_base/config.js. It was necessary to duplicate the sniffing code in both the loader (dojo.js) and the configuration module since we want to allow dojo to be loaded by foreign loaders. This duplication can be built out.
3. Non-browser configuration (e.g., node.js and rhino) have moved from dojo/_base/_loader/hostenv_*.js to dojo/_base/config*.js. Further, the bootstrap follows the philosophy, "assume the browser unless explicitly told otherwise." This is prudent since non-browser environments are on the local host, typically loaded via the file system, and a few extra bytes are inconsequential.
4. The most foundational dojo intialization, including defining the dojo object itself, found in dojo/_base/_loader/bootstrap.js moved to dojo/_base/kernel.js.
5. The dojo.ready (and the alias dojo.addOnLoad) moved to dojo/_base/load.js.
6. The v1.6- synchronous loader API (dojo.provide, dojo.require et al) back compat layer is newly implemented in dojo/_base/loader.js and dojo.js. This machinery is has-bracketed and may be easily built-out for AMD-only applications.
7. The browser version sniffing code found in dojo/_base/_loader/hostenv_browser.js moved to dojo/_base/sniff.js.
8. dojo.getXhr and dojo._getText found in dojo/_base/_loader/hostenv_browser.js and dojo/_base/_loader/loader.js respectively moved to dojo.js. The dojo.getXhr code is duplicated and has-bracketed in dojo/_base/xhr.js for cases when dojo is used with a foreign loader; dojo._getText is not available with a foreign loader.
9. dojo._Url moved from dojo/_base/_loader/_loader.js to dojo/_base/url.js. It is currently unused in dojo; it may be easily replaced by require.nameToUrl in dijit.
10. dojo/_base.js has been replaced by dojo/main.js IAW CommonJS package conventions. It conditionally loads dojo/_base/browser.js depending upon the environment.

The bootstrap is fairly easy to understand. The so-called "base" modules depend on dojo/_base/kernel which defines the dojo object (the dojo *object* not the dojo *module*). The dojo module is defined by dojo/main.js, and it depends on all the base modules. Though there are some interdependencies, loosely speaking...

• dojo/main defines the module dojo and depends on...
• the dojo base modules, which populate the dojo object with the base API and depends on...
• dojo/kernel, which creates the dojo object, which depends on...
• dojo/config, which computes the configuration object, and dojo/has, which defines the has API; these modules depend on nothing.

All of this machinery can operate mostly the same with either dojo's native loader or a foreign loader. There are a few functions not available with a foreign loader.

Outline of Changes to the dojo Tree

The following modules are essentially rewritten:

1. dojo/dojo new AMD loader with 1.x backcompat machinery.
2. dojo/cache empty now; implemented by the dojo/text plugin.
3. dojo/text the dojo/text plugin.
4. dojo/i18n the dojo/i18n plugin; all v1.6- i18n API is implemented through this module.
5. dojo/has the has.js API.
6. dojo/main the dojo package main module (essentially the old _base.js).
7. dojo/_base/browser dojo base modules for the browser environment.
8. dojo/_base/config all configuration sniffing/processing.
9. dojo/_base/configNode configuration for node.js.

10. dojo/_base/configRhino configuration for rhino.js.
11. dojo/_base/kernel creates the dojo object.
12. dojo/_base/load the dojo.addOnLoad/ready API; this is now a priority queue.
13. dojo/_base/loader the dojo.provide/require et al API.
14. dojo/_base/sniff browser sniffing code (only) from dojo/_base/_loader/_hostenvBrowser.js.
15. dojo/_base/unload window unload API.
16. dojo/_base/url dojo._Url API.

The following modules have minor changes:

1. dojo/_base/array removed native Javascript collection functions as per mailing list discussion.
2. dojo/_base/declare hasified IE enumeration bug; TODO: hasify shaman's rituals.
3. dojo/_base/xhr included has-bracketed xhr sniffing for use with foreign loaders.
4. dojo/_base/lang hasified IE enumeration bug.
5. dojo/_firebug moved dojo.deprecated and dojo.experimental out to dojo/_base/kernel.
6. dojo/parser used dojo.ready priority queue to remove dependency on dojo._loaders.
7. dojo/uacss used dojo.ready priority queue to remove dependency on dojo._loaders.
8. dojo/package.json added a few properties for the new builder.

All tests were modified to use define and require in place of dojo.provide and dojo.require so that they may be executed asynchronously. No changes were made to the actual tests contained within the test modules. The remaining dojo modules are not affected by this enhancement other that to remove the explicit module ids in the define statements, thereby making all modules anonymous.

Outline of Changes to the dijit Tree

1. The explicit module ids were removed from all modules, thereby making all modules anonymous.
2. dijit/test/test_colorPalette was modifed to operate either synchronously or asynchronously.
3. dijit/themes/themetester.html was slightly modified so it would work with anonymous modules.
4. dijit/_base/wai was modified to use the ready queue to removed the dependency on dojo._loaders.
5. The attempt to automatically create a savetextarea was deleted from dijit/_editor/richText as this code will not work reliably in async mode and has been problematic. The BackForward? test was modified by explicitly including a savetextarea.
6. dijit/tests/_testCommon was modified to use require.
7. dojo/package.json added a few properties for the new builder.

Outline of Changes to the dojox Tree

1. A package main module was added.

Outline of Changes to the util Tree

1. DOH was in need of some attention as it had been hacked on with many "quick fixes" and was becoming increasingly unreliable. It was generally cleaned up and turned into a proper set of AMD modules that form a small CommonJS package. DOH was enhanced to work with node.js; rhino operation was verified; self tests were added.
2. The docscript was slighly modified to consume the AMD define function.
3. A new build program was added. This will be tracked under a separate ticket.

[Rawld Gill]

(In [24328]) added AMD loader, refs #12672 \!strict

[Rawld Gill]

(In [24329]) fixed unexpected whitespace change; refs #12672 \!strict

[Rawld Gill]

(In [24331]) enhanced docscript to handle anonymous modules with AMD define; refs #12672

[Sam Foster]

This change seems to have made doh dependent on dojo? It used to run standalone in rhino, and in the browser too IIRC. The doh/runner.sh no longer works as it passes runner.js directly into rhino, but presumably needs some wrapper to provide the AMD loader implementation before I can load that.

There were also other parameters for the rhino runner including testModule, dohBase. I can see why those are gone, but it breaks my proposed doh plugins patch in ticket:12625 (which is ok, I just need to rework it in the AMD world):

[ben hockey]

do you want bugs here or listed in separate tickets?

djConfig.modulePaths is not taken into consideration correctly (at all?). i can't figure out how to have trac accept script tags in my code blocks.

// first script tag
djConfig = {
    modulePaths: {my: '/somewhere/else'}
};

// script tag to load dojo

// script tag to load app
dojo.require('my.App');  // see console output below

loader/failed-sync
*my/App
../dojo/my/App.js

[Rawld Gill]

I created ticket (#12678) for DOH issues stepping from #12672 (this ticket). Please report DOH issues to that ticket.

[Rawld Gill]

Replying to sfoster:

This change seems to have made doh dependent on dojo? It used to run standalone in rhino, and in the browser too IIRC. The doh/runner.sh no longer works as it passes runner.js directly into rhino, but presumably needs some wrapper to provide the AMD loader implementation before I can load that.

There were also other parameters for the rhino runner including testModule, dohBase. I can see why those are gone, but it breaks my proposed doh plugins patch in ticket:12625 (which is ok, I just need to rework it in the AMD world):

Check out the README in util/doh which explains some of these issues.

util/doh/runner.sh was broken, but is now fixed (see #12625)

I made DOH dependent on dojo since, with AMD, dojo can be completely sandboxed, and therefore there is no reason to write/maintain duplicate code. This design decision can be tuned by including only specific dojo modules needed by DOH if necessary.

We should be able to easily enhance the patch in #12625 to use AMD module loading. That way there is one standardized way to extend a program and thereby eliminate machinery that duplicates function. I will help with #12625 going forward.

[Rawld Gill]

Replying to neonstalwart:

do you want bugs here or listed in separate tickets?

djConfig.modulePaths is not taken into consideration correctly (at all?). i can't figure out how to have trac accept script tags in my code blocks.

// first script tag
djConfig = {
    modulePaths: {my: '/somewhere/else'}
};

// script tag to load dojo

// script tag to load app
dojo.require('my.App');  // see console output below

loader/failed-sync
*my/App
../dojo/my/App.js

The modulePaths backcompat machinery was not properly moved forward from 1.6. This is a bug I will repair. Thanks for the find.

[Rawld Gill]

Please report issues as follows:

• dojo, dijit, dojox problems caused by new loader/boot: this ticket
• new builder problems: #12673
• DOH issues caused by new loader/boot: #12625

If an issue becomes big, we'll take it to another ticket.

[Rawld Gill]

Replying to rcgill:

Please report issues as follows:

• dojo, dijit, dojox problems caused by new loader/boot: this ticket
• new builder problems: #12673
• DOH issues caused by new loader/boot: #12625

If an issue becomes big, we'll take it to another ticket.

Change 1: make that #12678 for DOH issues.

[Rawld Gill]

Replying to rcgill:

Replying to sfoster:

This change seems to have made doh dependent on dojo? It used to run standalone in rhino, and in the browser too IIRC. The doh/runner.sh no longer works as it passes runner.js directly into rhino, but presumably needs some wrapper to provide the AMD loader implementation before I can load that.

There were also other parameters for the rhino runner including testModule, dohBase. I can see why those are gone, but it breaks my proposed doh plugins patch in ticket:12625 (which is ok, I just need to rework it in the AMD world):

Check out the README in util/doh which explains some of these issues.

util/doh/runner.sh was broken, but is now fixed (see #12625)

I made DOH dependent on dojo since, with AMD, dojo can be completely sandboxed, and therefore there is no reason to write/maintain duplicate code. This design decision can be tuned by including only specific dojo modules needed by DOH if necessary.

We should be able to easily enhance the patch in #12625 to use AMD module loading. That way there is one standardized way to extend a program and thereby eliminate machinery that duplicates function. I will help with #12625 going forward.

Change 1: util/doh/runner.sh is fixed in #12678

[bill]

(In [24338]) dojo coding style / lint fixes, refs #12672 !strict

[bill]

(In [24339]) dojo coding style fixes, refs #12672 !strict

[bill]

(In [24340]) add some missing dependencies. unfortunately this is causing load errors in themeTester.html. refs #12672

[bill]

(In [24341]) don't use <script> tags to include dojo modules. add missing dependencies. refs #12672.

[Rawld Gill]

(In [24342]) fixed deps order in require application; refs #12672

[Rawld Gill]

(In [24345]) fixed improper define refactor; refs #12672

[bill]

(In [24352]) Any file that reference dojo.isIE etc. needs to include sniff.js, this fixes many (but not all) of the test failures on IE. Refs #12672 !strict.

[bill]

(In [24353]) fix has("ie"), refs #12672 !strict

[bill]

(In [24354]) rollback spurious spacing/tabbing changes causing some of the test failures refs #12672 !strict

[Rawld Gill]

(In [24361]) fixed inconsistent ordering of define deps and factory params; refs #12672

[Rawld Gill]

(In [24362]) fixed incorrect relative mid; refs #12672

[Rawld Gill]

(In [24363]) added dojo.registerModulePaths to backcompat loader; refs #12672; \!strict

[ben hockey]

req.ready does not account for the following signature:

dojo.ready(this, function () { ... });

it assumes that this is a function that needs to be called because it only detects that it should be a context if the callback is a string.

[bill]

(In [24365]) Fix merge error, a line was mysteriously deleted. Refs #12672 \!strict

[Rawld Gill]

(In [24369]) fixed whitespace; refs #12672; \!strict

[Rawld Gill]

(In [24370]) fixed improper assumed global variable; refs #12672

[Rawld Gill]

(In [24371]) improved formatting; refs #12672;

[Rawld Gill]

(In [24372]) improved formatting; refs #12672

[Rawld Gill]

(In [24373]) improved formatting; refs #12672

[Rawld Gill]

(In [24374]) improved formatting; fixed whitespace; refs #12672; \!strict

[Rawld Gill]

(In [24376]) fixed module doc header format; refs #12672; \!strict

[bill]

(In [24377]) a few more whitespace fixes, refs #12672 !strict

[bill]

I'm getting serious problems running the regression on webkit (specifically on chrome). the dijit/tests/runTests.html doesn't run at all, plus I get (the same?) failure in dojo/tests/html/test_set.html.

Probably something with firebug lite.

[bill]

(In [24379]) Remove temporary closure added in [24094], it's no longer needed. Refs #12519, #12672 !strict.

[bill]

(In [24380]) more whitespace fixes, refs #12672 !strict

[ben hockey]

patch to fix comment:25

[Rawld Gill]

(In [24382]) moved firebug boot to later in dojo boot to avoid undefined objects when booting firebug; refs #12672; \!strict

[Rawld Gill]

(In [24383]) hacks to firebug to sometimes avoid a race condition; re-enabled dojo.config.isDebug; cleaning dojo.js; refs #12672; \!strict

[Rawld Gill]

(In [24395]) improved config processing in boot; added config tests; removed firebug hacks and replaced with soln; refs #12672; \!strict

[Rawld Gill]

(In [24396]) improved config processing in boot; added config tests; removed firebug hacks and replaced with soln; refs #12672; \!strict

[Rawld Gill]

(In [24410]) improved config impl in loader; fixed regression in builder caused by [24396]; refs #12672; refs #12673; \!strict

[Rawld Gill]

(In [24412]) updated djConfig attributes to data-dojo-config in core unit tests; added back isDebug config removed in [24328]; refs #12672; \!strict

[Rawld Gill]

(In [24416]) replaced absolute module ids with relative module ids on the road to zero abs module ids in dojo; refs #12672; \!strict

[bill]

(In [24435]) With new AMD loader direct <script> tags for loading modules aren't allowed. Refs #12672.

[bill]

(In [24436]) With new AMD loader direct <script> tags for loading modules aren't allowed. Refs #12672.

[bill]

(In [24437]) Replace call to private function that was removed from core, patch from Rawld, refs #12672.

[bill]

Recent changes have apparently broken the loader tests on IE9, running dojo/tests/runTests.html just gets the "unable to get property isDebug" error on all the initial (_base/loader) tests.

[bill]

Also, the tests don't load at all unless you first hit F12 [and open the console tab]. Not sure if that's related to your checkin or not.

[Rawld Gill]

(In [24447]) implemented debugAtAllCosts and CommonJS define.amd; fixed off-by-one bug; removed cruft and improved commentary; refs #12672; \!strict

[evan]

(In [24459]) Fixes #12359 change to new AMD/define() syntax for all Grid components, refs #12672, !strict.

[dante]

sample namespace as sibling of dojo/

[dante]

seems there is a regression in the way dojo.require() behaves. dojo.require has always assumed ../namespace for a modulePath (sibling of dojo/ tree) not explicitly defined in a dojoconfig.modulePaths obj. attached is a sample tree illustrating this issue.

<script src="../dojo/dojo.js"></script>
<script>dojo.require("siblingns.test")</script>

should attempt to load ../siblingns/test.js (relative to dojo.js) but it is attempting to load {{../dojo/siblingns/test.js}}} resulting in an "Synchronous XHR failed" message from the loader.

[ben hockey]

package.json is not valid json. unfortunately, there can be no comments in the file and this string doesn't parse ".*\.js$"

[ben hockey]

require.has is non-standard (ie more non-standard than the rest of the AMD "standard") and if dojo is loaded by a loader that doesn't implement it then we don't work. if we depend on require having has should we automatically augment an existing require if it doesn't have has (along with any other feature we expect from require)? in other words, do we need to feature detect require?

[ben hockey]

Replying to neonstalwart:

require.has is non-standard (ie more non-standard than the rest of the AMD "standard") and if dojo is loaded by a loader that doesn't implement it then we don't work. if we depend on require having has should we automatically augment an existing require if it doesn't have has (along with any other feature we expect from require)? in other words, do we need to feature detect require?

...OR should we make has independent of require.

[ben hockey]

Replying to neonstalwart:

require.has is non-standard (ie more non-standard than the rest of the AMD "standard") and if dojo is loaded by a loader that doesn't implement it then we don't work. if we depend on require having has should we automatically augment an existing require if it doesn't have has (along with any other feature we expect from require)? in other words, do we need to feature detect require?

fyi - the point of failure is in dojo/has.js

	var has = require.has;

	if(!has("loader-hasApi") && typeof has=="function"){
		// notice the condition is written so that if has("loader-hasApi") is transformed to 1 during a build
		// the conditional will be (!1 && typeof has=="function") which is statically false and the closure
		// compiler will discard the block.

calling has and then testing to see if it is a function seems like a logic error but the comments seem to suggest that this is intentional?

[ben hockey]

exports not defined when passed to the factory of a module that has no dependencies.

define(function (require, exports, module) {
    console.log('require: ', require);
    console.log('exports: ', exports);
    console.log('module: ', module);
});

should ​http://bugs.dojotoolkit.org/browser/dojo/trunk/dojo.js?rev=24447#L761 use module.cjs.exports rather than module.exports?

[ben hockey]

if i have registered a path to a module called listen via

require({
  paths: {
    listen: "path/to/listen"
  }
});

and then in the listen module, i use a relative path for a dependency

define(['./aop'], function (aop) { ... });

then the path for aop that is calculated by getModuleInfo (​http://bugs.dojotoolkit.org/browser/dojo/trunk/dojo.js?rev=24447#L626) is listen/.././aop which will compact to aop which is not going to return the module i'm requesting.

[ben hockey]

Replying to neonstalwart:

then the path for aop that is calculated by getModuleInfo (​http://bugs.dojotoolkit.org/browser/dojo/trunk/dojo.js?rev=24447#L626) is listen/.././aop which will compact to aop which is not going to return the module i'm requesting.

fwiw, it will try to return baseUrl/aop (in case that wasn't clear).

[Rawld Gill]

(In [24474]) improved has API detection (refs #12672); bracketed browser-only has tests (refs #24471); \!strict

[Rawld Gill]

(In [24475]) improved config, error, and trace APIs in loader; tuned deps vectors in _base modules; refs #12672; !strict

[Rawld Gill]

(In [24477]) fixed backcompat error so that external modules are siblings of the dojo tree; refs #12672; !strict

[Rawld Gill]

(In [24479]) removed debugAtAllCosts which was causing test stall; refs #12672

[Rawld Gill]

(In [24480]) added loader tests; refs #12672

[Rawld Gill]

Replying to neonstalwart:

req.ready does not account for the following signature:

dojo.ready(this, function () { ... });

Just checked and this seems to be working as of [24480].

[Rawld Gill]

Replying to dante:

seems there is a regression in the way dojo.require() behaves. dojo.require has always assumed ../namespace for a modulePath (sibling of dojo/ tree) not explicitly defined in a dojoconfig.modulePaths obj.

Thanks for the find. This is fixed in [24477].

[Rawld Gill]

Replying to neonstalwart:

require.has is non-standard (ie more non-standard than the rest of the AMD "standard") and if dojo is loaded by a loader that doesn't implement it then we don't work. if we depend on require having has should we automatically augment an existing require if it doesn't have has (along with any other feature we expect from require)? in other words, do we need to feature detect require?

The module dojo/has implements the has API when dojo is being used with a foreign loader. I'm sure there will be some details to work out when I/we test dojo with another loader, but there is nothing in the design intended to lock dojo into our own loader.

See also ​http://livedocs.dojotoolkit.org/developer/design/bootstrap

[Rawld Gill]

Replying to neonstalwart:

Replying to neonstalwart:

require.has is non-standard (ie more non-standard than the rest of the AMD "standard") and if dojo is loaded by a loader that doesn't implement it then we don't work. if we depend on require having has should we automatically augment an existing require if it doesn't have has (along with any other feature we expect from require)? in other words, do we need to feature detect require?

fyi - the point of failure is in dojo/has.js

	var has = require.has;

	if(!has("loader-hasApi") && typeof has=="function"){
		// notice the condition is written so that if has("loader-hasApi") is transformed to 1 during a build
		// the conditional will be (!1 && typeof has=="function") which is statically false and the closure
		// compiler will discard the block.

calling has and then testing to see if it is a function seems like a logic error but the comments seem to suggest that this is intentional?

Right...that was written late at night :)...it's been changed.

[ben hockey]

in configNode.js, eval and injectUrl both use process.compile which gives warnings about being deprecated. besides this, in my experience (ie, can't find a doc to confirm this), the url hint provided to process.compile (or require('vm').runInThisContext its alternative) needs to be an absolute url for breakpoints to work for remote debugging.

[ben hockey]

given the url of my page is at http://some.server.com/app/, doing the following with requirejs gives the init module found at http://some.server.com/absolute/path/init.js but with dojo it tries http://some.server.com/app/init.js

require({
  baseUrl: '/absolute/path',
  packages: [
    {
      name: 'dojo',
      location: '/different/absolute/path/to/dojo',
      main: 'lib/main',
      lib: '.'
    }
  ]
},
['init', 'dojo'], function (init, dojo) {
  // ...
});

i could see arguments for either way being right so i changed the 'init' dependency to './init' hoping that it would do the right thing but instead it tried to load http://some.server.com/app//absolute/path/init.js (note that // is in the actual output)

my preference would be to follow requirejs in this case but i'd live with a workable version that needed './init' if it had to be like that.

[ben hockey]

requirejs doesn't cope with '.' as a dependency - ​https://github.com/jrburke/requirejs/blob/0.24.0/require.js#L1267 explicitly checks for './' or '../'

should we ask james to make a change or should we avoid using '.'?

personally, i like the trickiness of using the '.' but i feel like we will be more readable and more likely to avoid problems by explicitly using 'dojo', 'dijit' and 'dojox' instead.

[Rawld Gill]

Replying to neonstalwart:

in configNode.js, eval and injectUrl both use process.compile which gives warnings about being deprecated. besides this, in my experience (ie, can't find a doc to confirm this), the url hint provided to process.compile (or require('vm').runInThisContext its alternative) needs to be an absolute url for breakpoints to work for remote debugging.

You're right. The code was developed under node v0.2.6 and needs to be updated to the current node version.

[bill]

(In [24494]) improved formatting; fixed whitespace; refs #12672 !strict

[bill]

(In [24495]) remove stray dojo.require(), and use AMD instead, refs #12672

[Rawld Gill]

Replying to neonstalwart:

exports not defined when passed to the factory of a module that has no dependencies.

define(function (require, exports, module) {
    console.log('require: ', require);
    console.log('exports: ', exports);
    console.log('module: ', module);
});

fixed in 24498

[Rawld Gill]

(In [24502]) added feature to push top-level config into has cache; cleaned cruft; refs #12672; !strict

[bill]

As reported on dojo-interest, dojo/tests/back.html is broken. Not surprising since it loads back.js via a <script> tag, and calls dojo.back.init() before dojo.ready() fires. However, the problem is that dojo.back.init() needs to be called before the document finishes loading. So not sure how/if this can be repaired, besides telling users to put back.js into their build of dojo.js.

[Rawld Gill]

(In [24529]) removed has feature dojo-boot; renamed several has feature names to be has.js-project-compliant; refs #12672; !strict

[Rawld Gill]

(In [24530]) fixed missed has feature rename in [24529]; refs #12672;

[Rawld Gill]

(In [24536]) fixed bug in backcompat hack for module paths set prior to boot; refs #12672; !strict

[phk]

Hi,

I'm not sure it's related, but when I try to generate layers for my application with the latest build it fails with the following message:

error loading uri: /data/release/Wfp2/dojo/_base.js, exception: Error: Could not load 'dojo._base.lang'; last tried '/data/release/Wfp2/dojo/_base/lang.js'

However /data/release/Wfp2/dojo/_base/lang.js exists...

[Rawld Gill]

(In [24551]) added support for file protocol in ie7; fixes #12809; refs #12672; !strict

[Rawld Gill]

(In [24552]) fixed bad module-id in define application; refs #12672

[Rawld Gill]

(In [24553]) added has feature to control behavior that top-level-modules are siblings of dojo; fixed backcompat behaviro of dojoConfig.require; refs #12672; !strict

[Chris Mitchell]

REGRESSION: Not handling non-AMD v1.6-style i18n modules properly. Looks like dojo/i18n line 125 gets xhr results, but they never end up getting put into a nls cache properly, resulting in downstream root=undefined problem in dojo/i18n line 84. Good test case is dojox/widget/tests/test_ColorPicker.html

[bill]

(In [24578]) comment / spacing fixes, sort of refs #12672 !strict.

[Rawld Gill]

(In [24601]) improved i18n machinery backcompat to handle both pre- and post-AMD bundle formats; refs #12672; !strict

[Rawld Gill]

(In [24620]) fixed error in i18n backcompat with pre-AMD i18n bundles; refs #12672; !strict

[Rawld Gill]

(In [24621]) improved i18n to return a new object with each request to prevent client code from stepping on cached bundles; refs #12672; !strict

[Chris Mitchell]

There's still some issues remaining in i18n compat for AMD loader. Here's info and a testcase from one of our teams. Best regards, Chris

---

I tested todays trunk, it is better but not completely OK yet:

The dojo.locale does not seem to be initialized from the djConfig variable. I also tried dojoConfig and the djconfig attribute of the dojo.js script element, whatever I do dojo.locale is set to the default browser locale (en-us by default). The only way to change the locale is to change the browser's locale (e.g., using about:config and changing general.useragent.local in Firefox).

Even after changing the browser's locale, the localized nls files are not loaded: the root (en-us) messages are loaded instead.

I am attaching the test that I use (to be extracted in the same directory as dojo/dijit/dojox). When run in a en-us browser, it will fail because the dojo.locale is not set according to the djConfig setting. If the browser's locale is changed to "fr", the test will fail because the loaded bundles do not match the locale.

The test passes OK on dojo 1.6, and also on the dojo 1.7 trunk versions prior to 4/1/2011.

---

[Rawld Gill]

(In [24644]) more improvement to plugin behavior so that plugin determines when plugin resource needs to be reloaded; refs #12672; !strict

[Rawld Gill]

(In [24650]) fixed error in i18n backcompat with pre-AMD i18n bundles; refs #12672; !strict

[Rawld Gill]

(In [24651]) added support and tests for cdn build (mixed-mode xd async and local sync loading); refs #12672; !strict

[ben hockey]

it looks like some of this block ​http://bugs.dojotoolkit.org/browser/dojo/trunk/dojo.js?rev=24651#L435 could be merged with the next block - they have the same if condition and they both get all the scripts and iterate over them. also, i'm confused as to why there is a check for require.js - this was really how i came to be looking at this code. will dojo support the data-main property like require.js?

[Rawld Gill]

Replying to neonstalwart:

it looks like some of this block ​http://bugs.dojotoolkit.org/browser/dojo/trunk/dojo.js?rev=24651#L435 could be merged with the next block - they have the same if condition and they both get all the scripts and iterate over them. also, i'm confused as to why there is a check for require.js - this was really how i came to be looking at this code. will dojo support the data-main property like require.js?

I've debated this block myself. My idea was that I wanted dojo.js to be a drop-in replacement for RequireJS. The only thing you'd have to do is either rename dojo.js or have your server alias require.js to dojo.js. I don't feel strongly about this concept and welcome more feedback.

Seems that if we keep it, then it should be bracketed by a different has feature name...if it costs 1 byte in a built version that doesn't want it, then I definitely will cut it.

[liucougar]

(In [24711]) refs #12672: consolidate duplicate doh._testRegistered in iframe doh (this makes sub-tests registered in html test page not show up under the parent test on the left menu)

!strict

[liucougar]

(In [24713]) refs #12672: timeout should be set to a number if missing, otherwise it won't be passed to _registerUrl() by register()

this broke backward compatibility

!strict

[Rawld Gill]

Replying to liucougar:

(In [24713]) refs #12672: timeout should be set to a number if missing, otherwise it won't be passed to _registerUrl() by register()

this broke backward compatibility

!strict

Did you see this change cause a different behavior? Because if you look at the implementation of

_registerUrl() in _browserRunner.js you'll see

timeout: timeout||10000, // 10s

Let me know because I'm about to replace doh.register with an enhanced version and I think that will lose this change.

Thanks!

[liucougar]

Replying to rcgill:

Did you see this change cause a different behavior? Because if you look at the implementation of

yes, it makes all of our tests which does not specify a timeout explicitly not registered at all. the problem is in function doh.register of file runner.js:

        if(arity==3){
                if(isNumber(a3)){
                        // (group, url, timeout)
                        this._registerUrl(a1, a2, a3);
                }else if(isType(a3)){
                        ...
                }
                return;
        }

if a3 is not a number, _registerUrl is never called

[Chris Mitchell]

is it safe to disregard the
end v1.x content
comment blocks in i18n files for 1.7? Adam mentioned that these were used in the 1.6 loader.

[Rawld Gill]

(In [24744]) fixed i18n plugin to strip trailing slash from absolute module id check optimization; refs #12672; !strict

[Rawld Gill]

(In [24745]) fixed bug in stripping logic in text plugin; refs #12672

[Rawld Gill]

(In [24751]) fixed eval hint to be compat with ie9; thanks luicougar; refs #12672; !strict

[Rawld Gill]

(In [24753]) ported forward changes in [24750] that affected dojox; refs #12672

[Rawld Gill]

(In [24754]) fixed package.json to be valid JSON; refs #12672; refs #12678

[Rawld Gill]

Replying to neonstalwart:

fixed in [24754]

[bill]

(In [24765]) remove stray dojo.require() calls, plus spacing fixes, refs #12672 !strict

[Rawld Gill]

(In [24767]) added feature and tests to publish AMD result when module loaded with dojo.require; optional on config flag publishRequireResult, default true; refs #12672; !strict

[Rawld Gill]

(In [24768]) controlled recursive depth of checkComplete; simplified ie handling of cached modules; refs #12672; !strict

[Rawld Gill]

(In [24769]) changed relative module ids in deps vectors to point to dojo/main instead of dojo; refs #12672; !strict

[Rawld Gill]

Replying to chrism:

is it safe to disregard the
end v1.x content
comment blocks in i18n files for 1.7? Adam mentioned that these were used in the 1.6 loader.

Yes, these are not required (but not harmful) in 1.7.

[Rawld Gill]

(In [24770]) removed 1.6 AMD tests no longer relevant; refs #12672

[bill]

(In [24771]) remove unneeded closure, refs #12672, !strict

[bill]

(In [24774]) remove unneeded closure, fix spacing, refs #12672, !strict

[bill]

(In [24775]) remove unneeded closure, fix spacing, refs #12672, !strict

[bill]

(In [24778]) Spacing fixes and module summaries, refs #12672 !strict. Most of the modules indent inside the define() block but some don't; I didn't standardize that.

[bill]

(In [24779]) spacing fixes and module summaries, refs #12672 !strict

[bill]

(In [24780]) spacing fixes and module summaries, refs #12672 !strict

[bill]

(In [24782]) spacing fixes and module summaries, refs #12672 !strict

[bill]

(In [24783]) Spacing fixes and module summaries, refs #12672 !strict. Most of the modules indent inside the define() block but some don't; I didn't standardize that.

[bill]

(In [24784]) Use template pulled in from text! dependency rather than calling dojo.cache(), refs #12672 !strict

[Chris Mitchell]

Bill, does the text! change break internStrings option in the build, or is rawld already planning to make those changes?

[Chris Mitchell]

also, should we be doing similar changes in dojox/* as we port them to amd?

[Chris Mitchell]

also, should we be using dojo/text! or text! (for better compat with requirejs

[Rawld Gill]

Replying to chrism:

Bill, does the text! change break internStrings option in the build, or is rawld already planning to make those changes?

I've planned for this. The semantics of internStrings are slightly different in the new builder:

case 1: AMD module: whenever a module has a text! dependency, that dependency is aggregated with the module during the build (like a mini implied layer...possibly as part of an explicit layer)

case 2: dojo.provide/require module: the string is added to the dojo.cache application (which will still be there since the option doesn't exist to use the text! plugin)...as has been done in the past.

[Rawld Gill]

Replying to chrism:

also, should we be doing similar changes in dojox/* as we port them to amd?

It will work either way. It boils down to choosing between

"text!some/bundle/name" in the deps vector

compared to

dojo.cache("some.bundle", "name") where the string is used.

The text! technique eliminates the need for yet-another-regular-expression in the builder, which is nice.

[Rawld Gill]

Replying to chrism:

also, should we be using dojo/text! or text! (for better compat with requirejs

Either will work with requirejs. dojo's text plugin is better than requirejs's because it leverages dojo. Also you could map one to the other.

My preference is to use dojo/text because it explicitly says we want to leverage dojo, and if the user insists on using something else, then they are at least somewhat responsible for any consequences.

[Rawld Gill]

(In [24800]) removed the experimental *ready module and replaced with domReady plugin and additional require.ready signature; renamed has feature dojo-domloaded-api to dojo-dom-ready-api; propagated changes to tests; refs #12672; !strict

[Rawld Gill]

(In [24801]) improved plugin detection to allow an empty resource id; refs #12672; !strict

[Rawld Gill]

(In [24802]) upgraded nodeConfog to node.js v0.4.7 ; refs #12672

[Rawld Gill]

(In [24803]) removed v1.6 dojo/lib since it's not used in 1.7; refs #12672

[Rawld Gill]

(In [24804]) moved firefox-extension and spidermonkey config files to _base iaw new structure; refs #12672

[Rawld Gill]

(In [24805]) removed v1.6 dojo/_base/_loader since it's not used in 1.7; you've been a good ship sync loader, great thanks to James Burke for all his hard and professional work; refs #12672

[bill]

(In [24820]) Changing to recommended style for AMD loading, as I understand it, refs #12672

[bill]

(In [24825]) fix typos in [24747], refs #12672

[Rawld Gill]

(In [24835]) fixed typo; refs #12672

[Rawld Gill]

(In [24836]) commented out cdn loader test until it can be completed; refs #12672; !strict

[ben hockey]

require({
    baseUrl: '/abs/path/to/base'
},
['init'], function (init) { 
    // ... 
});

tries to fetch 'init' from '/abs/path/to/init' but i think it should be 'abs/path/to/base/init'

adding a path mapping fixes it:

require({
	baseUrl: '/abs/path/to/base',
	paths: {
		init: 'init'
	}
},
['init'], function (init) { 
	// ... 
});

but i would have expected that this mapping wouldn't be necessary

[Rawld Gill]

(In [24859]) removed abs mid; refs #12672; !strict

[Rawld Gill]

(In [24874]) improved handling of package.lib config variable; refs #12672; !strict

[bill]

prospective patch to fix return types of dojo/_base modules

[bill]

(In [24904]) fix typo, refs #12672 !strict

[ben hockey]

should dojox have a package.json since it has a main.js ?

[ben hockey]

dojo/text and dojo/i18n can't be mapped to top-level module ids - eg text and i18n respectively. given that there will be pre-existing usage of text and i18n is there a way to support this mapping for the sake of compatibility with existing use cases?

[bill]

updated return values from dojo/_base modules

[bill]

(In [24963]) Remove stray dojo.provide(), refs #12359, #12672, !strict.

[Kris Zyp]

When I tried loading 1.6- modules from dojox while in async mode, the loading fails because the calling factory function gets executed before all the 1.6-'s dependencies are synchronously loaded. For example, if I have dojo's config with async:true and then have a module:

define(dojox.gantt.GanttChart?, function(Chart){

this is executed after dojox/gantt/GanttChart.js, but before any of GanttChart?.js's dependencies are loaded

});

Attached is my attempt at a patch. Can you check to make sure it looks OK?

[bill]

(In [24987]) This code apparently expects the class name to match the module name, so splitting up each class to a separate file. Refs #12672 !strict.

[bill]

(In [24988]) indentation fix, refs #12672 !strict

[Rawld Gill]

(In [25000]) fixed bug in require.toUrl when name is a relative path with no reference module; refs #12672; !strict

[Rawld Gill]

(In [25008]) improved loader to mark modules w/out factories as immediately executed; improved dojo/text plugin process with built code; refs #12672; refs #12673; !strict

[ben hockey]

Replying to rcgill:

(In [25000]) fixed bug in require.toUrl when name is a relative path with no reference module; refs #12672; !strict

this adds a bug where the text plugin tries to fetch files as some/file.js.html in some circumstances - working on a minimal test to demonstrate

[Kris Zyp]

(In [25014]) Fix loading of legacy dojo modules, fix absolute check in nameToUrl, refs #12672 !strict

[ben hockey]

Replying to neonstalwart:

Replying to rcgill:

(In [25000]) fixed bug in require.toUrl when name is a relative path with no reference module; refs #12672; !strict

this adds a bug where the text plugin tries to fetch files as some/file.js.html in some circumstances - working on a minimal test to demonstrate

test case:

define('test', function () {
	return {};
});
require(['dojo/text!test.html'], function (test) {
	console.log(test);
});

it seems that if the name of the html file (without the extension) matches the id of a module that has already been defined then .js is added to the url such that test.html becomes test.js.html

[ben hockey]

nevermind... r25014 fixed it while i was making the test case - thanks kzyp

[ben hockey]

​http://bugs.dojotoolkit.org/browser/dojo/trunk/dojo.js?rev=25014#L1044 from r25014 tries to use dojo.getObject but dojo doesn't always exist.

[ben hockey]

require.eval (used when dojo.config.async is not true) does not evaluate in the global scope. example: an html file contains

require(['test'], function () {
  console.log(test);
});

and test.js contains

var test = 'abc';

if you use async loading, test is a global but if you use synchronous loading test is not defined. the key to being able to see this is the use of var in test.js - of course without it, test will be global no matter what scope test.js is evaluated in.

[Rawld Gill]

(In [25061]) removed cjs package lib configuration machinery; refs #12672; !strict

[Rawld Gill]

(In [25063]) removed cjs package lib configuration; refs #12672

[Rawld Gill]

Replying to neonstalwart:

require.eval (used when dojo.config.async is not true) does not evaluate in the global scope. example: an html file contains

require(['test'], function () {
  console.log(test);
});

and test.js contains

var test = 'abc';

if you use async loading, test is a global but if you use synchronous loading test is not defined. the key to being able to see this is the use of var in test.js - of course without it, test will be global no matter what scope test.js is evaluated in.

There's more to it. In fact, test won't be defined in ie and some other browsers because of the way eval is defined in *both* 1.6- and 1.7 (though 1.7 is much better).

So, this is expected behavior.

[ben hockey]

Replying to neonstalwart:

​http://bugs.dojotoolkit.org/browser/dojo/trunk/dojo.js?rev=25014#L1044 from r25014 tries to use dojo.getObject but dojo doesn't always exist.

transferred to #13018

[ben hockey]

Replying to neonstalwart:

dojo/text and dojo/i18n can't be mapped to top-level module ids - eg text and i18n respectively. given that there will be pre-existing usage of text and i18n is there a way to support this mapping for the sake of compatibility with existing use cases?

transferred to #13019

[ben hockey]

Replying to neonstalwart:

require({
    baseUrl: '/abs/path/to/base'
},
['init'], function (init) { 
    // ... 
});

tries to fetch 'init' from '/abs/path/to/init' but i think it should be 'abs/path/to/base/init'

<snip>

transferred to #13020

[Kris Zyp]

(In [25098]) Fix dojo.getObject to run without dojo, refs #12672 !strict

[Rawld Gill]

(In [25124]) fixed typo in test name; refs #12672

[Rawld Gill]

(In [25154]) removed unused lib tree and resources in dijit ; refs #12672

[Rawld Gill]

(In [25155]) removed unnecessary dependency; refs #12672; fixes #12790; !strict

[Rawld Gill]

(In [25182]) cleaned up has feature flag names; refs #12672; !strict

[Rawld Gill]

(In [25188]) removed unused has feature values; improved has build plugin to remove unreferenced modules; refs #12672

[Chris Mitchell]

closing out this enhancement for 1.7. Please use new tickets for further issues.

[bill]

(In [25195]) Put back unload require, it's needed again. Refs #13065, #13072, #12672, #12790 !strict.

[Kris Zyp]

(In [25204]) Don't silently swallow irrational path errors, refs #12672 !strict

[Rawld Gill]

All problem reports on this ticket have either been resolved or moved to other tickets.

Please open a new ticket to report problems with the 1.7 loader.

You may ref this ticket when committing minor/tuning changes to the loader until v1.7 release.

[Rawld Gill]

(In [25240]) rolls back [25014] (except of toUrl fix) and [25098]; applies different, less intrusive soln; adds test for issue; refs #12672; !strict

[Rawld Gill]

(In [25241]) cleaned cruft; refs #12672; !strict

[Kris Zyp]

(In [25244]) Make when() available on dojo/_base/Deferred export... (are all _base modules supposed to return dojo?), refs #12672 !strict

[bill]

(In [25260]) don't give two tests the same name, it makes the progress bar and percent readout act funny, refs #12672; !strict

[bill]

(In [25261]) don't give two tests the same name, it makes the progress bar and percent readout act funny, refs #12672; !strict

[bill]

(In [25263]) make test names consistent w/rest of dojo test names, refs #12672; !strict

[Rawld Gill]

(In [25291]) dojo/_base.js is not used in v1.7+; refs #12672

[Rawld Gill]

(In [25292]) dojo/_base.js is not used in v1.7+; refs #12672

[Rawld Gill]

(In [25294]) fixed plugin not being loaded in sync mode under some conditions; refs #12672; !strict

[Rawld Gill]

(In [25295]) fixed whitespace; refs #12672; !strict

[Rawld Gill]

(In [25302]) fixed loading cached modules in ie; refs #12672, #12673; !strict

[Rawld Gill]

(In [25487]) fixed mistake in naming when pushing config vars into has cache; refs #12672; !strict

[ben hockey]

(In [25789]) change locale in configNode to be something usable by i18n. refs #12672

[bill]

In [26008]:

Change has("webKit") (mixed case) to has("webkit") (all lowercase), as briefly discussed in the meeting, refs #12672 !strict.

[Bryan Forbes]

In [26032]:

Move dojo/_base/array.js to dojo/array.js. refs #12672 !strict

[Bryan Forbes]

In [26033]:

Fixed indexOf and lastIndexOf, added back-compat shim in _base, and
updated tests. refs #12672 !strict

[Bryan Forbes]

In [26034]:

Move dojo/_base/NodeList.js to dojo/NodeList.js. refs #12672 !strict

[Bryan Forbes]

In [26035]:

Use _base/kernel instead of _base/window in array.js. refs #12672 !strict

[Bryan Forbes]

In [26036]:

Back out move of NodeList?. refs #12672 !strict

[Bryan Forbes]

In [26044]:

Removed unused declaration. Fixed docs. refs #12672 !strict

[Bryan Forbes]

In [26045]:

Change === to == in indexOf and lastIndexOf for back-compat. refs #12672 !strict

[bill]

In [26046]:

make dijit use "dojo/array" instead of "dojo/_base/array", see [26033], refs #12672 !strict.

[bill]

In [26062]:

fix typo in API doc, refs #12672 !strict

[evan]

In [26115]:

Refs #12672 !strict use has('webkit') instead of has('webKit') in Grid, also see [26008]

[Bryan Forbes]

In [26125]:

Moved base definition of NodeList? to dojo/query.js. refs #12672 !strict

[Bryan Forbes]

In [26126]:

Broke DOM functions of NodeList? out into NodeList?-dom. Changed _base/NodeList to provide back-compat shim. refs #12672 !strict

[Bryan Forbes]

In [26127]:

Updated dependency lists for NodeList? extensions. refs #12672 !strict

[Bryan Forbes]

In [26128]:

Added back-compat shim to get dojo.query with previous default extensions. refs #12672 !strict

[Bryan Forbes]

In [26150]:

Removed unused parameter. refs #12672 !strict

[Eugene Lazutkin]

In [26189]:

array: more compact, yet faster and backwards compatible version of array extras, !strict, refs #12672.

[Kenneth G. Franqueiro]

In [26197]:

Added NodeList?-dom to dep list of ScrollingTabController? (needed for style). Refs #12672, [26126]

[bill]

In [26201]:

delete _base/array.js, preparing to move dojo/array.js back to dojo/_base/array.js, refs #12672

[bill]

In [26203]:

move dojo/array.js back to dojo/_base/array.js, refs #12672 !strict

[Bryan Forbes]

In [26291]:

Add dojo._getText as property of dojo/_base/xhr return value. refs #12672 !strict

[ben hockey]

In [26294]:

fix typo from r26291. refs #12672 !strict

[Kenneth G. Franqueiro]

In [26309]:

Resolve a remaining dojo.* reference in mouse.js, refs #12672 !strict

[Kenneth G. Franqueiro]

In [26310]:

Change straggler instances of dojo.isQuirks to use has. Refs #12672. Ran dojo tests before and after with identical results.

[Kenneth G. Franqueiro]

In [26338]:

Replacing kernel.isQuirks references with has('quirks') and removing now-unneeded kernel dependencies. Enabled by [26334], refs #12672.

[ben hockey]

In [26804]:

get doh/tests/scopeTest and doh/tests/selfTest working.
refs #13956, #13957, #12672, #12740, #12678 !strict

[bill]

In [27344]:

remove "random" SVN revision number checked into file in [24328], refs #12672 !strict

[Kenneth G. Franqueiro]

In [27345]:

Attempt to restore automatic svn generation of revision for dojo.version in kernel.js; refs #12672 !strict

[bill]

In [27346]:

Make version number reported by dojo.version exactly equal to one in the checkin comment, refs #12672

[Kenneth G. Franqueiro]

In [27373]:

Mark kernel.js to properly update svn revision on 1.7 branch; refs #12672 !strict

[Adam Peller]

In [28538]:

use AMD ref for dnd manager Refs #12672 !strict

[bill]

In [28614]:

amd related cleanup: localize references to dojo "global", and use on() rather than dojo/connect, refs #12672 !strict.

[bill]

In [30389]:

Remove firebug-lite dependency from browserRunner.js, refs #12672 !strict. It was added in [24395] but doesn't seem to be necessary [anymore], even when running on IE6. I understand needing firebug-lite when running an individual test but I don't see the point of it in the test runner, since the test runner has a log pane already.

[bill]

In [30706]:

dijit/editor: fix indentation of code inside define() callbacks, refs #12672 !strict

[bill]

In [30707]:

dijit/form: fix indentation of code inside define() callbacks, refs #12672 !strict

[bill]

In [30708]:

dijit/layout: fix indentation of code inside define() callbacks, refs #12672 !strict

[bill]

In [30709]:

dijit/tree: fix indentation of code inside define() callbacks, refs #12672 !strict

[bill]

In [30710]:

dijit: fix indentation of code inside define() callbacks, refs #12672 !strict