avoiding dojo namespace collision between 1.0 and 0.4

[guest]

Alex, I mentioned this during your 0.9 presentation at The Rich Web Experience..

Can the dojo 1.0 release ensure there are no namespace collisions so that dojo 1.0 and 0.4 can (if necessary) co-exist with each other on the same pages? Upgrading enterprise architectures/applications that have the 0.4 dependency is more than an exercise, it'd be nice if we can transition from one to the other over a period of time.

You mentioned that it had been discussed before and you would work on getting this into the 1.0 release. I'm creating the ticket for tracking purposes...

[dante]

it seems like by design namespace collisions are going to be avoided. the easy one: dijit + dojox are new, so that leaves the compacted subset of methods that remain in core/base, most of which have been reduced to dojo.methodName ... though it is unreasonable to request the renaming of dojo.byId() ?

is it practical to expect two versions of dojo to exist on the same page? is there a way one can remove the stuff that is backwards compatible (dojo.byId() for instance) from an older release and slowly migrate while running both?

[jburke]

I'm going to pick this one up for now. I have some thoughts on how to allow dojo to fit into a custom namespace, and I'll see if I can get the idea worked out in time for 1.0. It may not make 1.0, maybe a 1.1.

Basic approach is to use some anonymous function closures to do the dojo setup, then allow changing the top level name from dojo to something else via either a djConfig setting or a build option. Any modules evaluated via dojo.require() would be done inside a function closure that sets up the namespace correctly.

Feel free to holler if you do not like the idea.

[jburke]

Just uploaded some patches to enable multiple versions of Dojo in a page. You can try it in action at:

http://dojotoolkit.org/~jburke/scope/dojo/tests/_base/_loader/scope04.html

(The URL may not work after a while)

Not sure if we can pick this up for 1.0 (may be too much change at this point), but approach looks promising.

Test page works in IE 6.0, FF 2.0.0.8, Safari 3 beta, and Opera 9.50

[alex]

this looks great. I'll give the patches a look tonight.

[jburke]

Patch for util/buildscripts, done against r11084

[jburke]

Patch for dojo core repo, done against r11084

[jburke]

Test file showing Dojo 0.4.3 and Dojo "1.0" loading in the same page, with widget parsing.

[jburke]

Test file showing Dojo 0.4.3 and jodo, a scope defined within a built dojo.js file.

[jburke]

XDomain test file showing Dojo 0.4.3 and jodo, a scope defined within a built dojo.js file.

[jburke]

Just updated the patches to match code in r11084 (specifically, after the NodeList? change from using a popup to define an array subclass for NodeList?).

I also added code to allow a build process to "burn in" the namespace it wants. With these latest changes, I think the following use cases are satisfied:

1) Someone wants to try Dojo 1.0 alongside Dojo 0.4.x.

2) Someone wants to use Dojo in their own JS library that they distribute, but they do not want to expose the dojo/dijit/dojox scopes outside of their built JS library. They just build one layer file that has all their JS code in it and want to define their custom scope to have the dojo code live under. These built "one file" libraries should function well alongside JS code that uses the explicit dojo/dijit/dojox names.

Possible issues:

1) There is a possibility that djConfigs for two different versions could be problematic. Ideally, say in bootstrap.js, make a copy of djConfig to something like dojo._djConfig and have all the code reference that version of djConfig. This is a larger code change though. Something we can probably float to a 1.1.

2) xdomain loading does not work out of the box: if you want to xd load some modules under a different scope, you have to do a custom build that sets the xdDojoScopeName to the other scope name. Not the ideal, but it works. I don't see an easy way around this problem. Main issue is that the xd.js file is loaded outside of the enclosed scope, and it happens asynchronously. We need to call the global that is created for the enclosed dojo scope.

3) These patches require the least amount of changes to existing code (no global search/replace for dojo/dijit/dojox), and uses scope tricks. A side effect of this though: when doing a mycustomdojoname.require("dojo.foo") the string inside the require call needs to be for "dojo.foo" and not "mycustomdojoname.foo". I can see where that might be a bit confusing.

4) Not all of dijit or dojox has been scrubbed to make sure it uses dojo._scopeName instead of "dojo/dijit/dojox" for strings that are used for timeouts/intervals or explicit DOM IDs/prefixes. Should not be a big problem for first release (since dijit and dojox are new namespaces), but need to scrub it down for 1.1.

[jburke]

util/buildscripts/jslib/dojoGuardStart.jsfrag did not come through the patch file. Explicitly including it here.

[jburke]

util/buildscripts/jslib/dojoGuardEnd.jsfrag did not come through the patch file. Explicitly including it here.

[jburke]

NOTE: Be sure to scrub iframe_history.html: It tries to grab the parent frame's "dojo" global object. Need to make it smarter.

[jburke]

Pushing to 1.1. Not comfortable with this level of change so close to the 1.0 release.

[jburke]

(In [12008]) Refs #4573: putting in scope changes. Say hello to _scopeName for string IDs. !strict

[jburke]

(In [12009]) Refs #4573: putting in scope changes. Say hello to _scopeName for string IDs. !strict

[jburke]

(In [12010]) Refs #4573: putting in scope changes. Say hello to _scopeName for string IDs. !strict

[jburke]

(In [12011]) Refs #4573: putting in scope changes. Say hello to _scopeName for string IDs. !strict

[jburke]

(In [12112]) Refs #4573. Moving scope tests to their own directory

[jburke]

(In [12119]) Refs #4573. Allow for burning in a djConfig for a built version. Still need to convert codebase to dojo.config, but this is a first step. !strict (redeclaration errors)

[jburke]

(In [12120]) Refs #4573. Moving scope tests to own directory, adding a djConfig burn in test.

[jburke]

(In [12121]) Refs #4573: Convert to dojo.config instead of djConfig internally.

[jburke]

(In [12122]) Refs #4573: Convert to dojo.config instead of djConfig internally. !strict

[jburke]

(In [12123]) Refs #4573: Convert to dojo.config instead of djConfig internally. !strict

[jburke]

(In [12124]) Refs #4573: Convert to dojo.config instead of djConfig internally. !strict

[jburke]

(In [12235]) Refs #4573: get debugAtAllCosts to work with scope changes.

[jburke]

(In [12237]) Fixes #4573: Removed the path remapping in loadModule, since it messed up the ability to make your own namespace for dojo, but add your own code to it outside the dojo directory. Also finished book documentation.

[guest]

Hi, I'v been trying to get this feature to work with the nightly and was very successful except for one big issue. The first time the page is loaded in IE7 , the namespaced dojo 1.0 is not fully loaded. In fact it dies right at the beginning of dojo.js, when there is a test for the console object.

By commenting the following block of code i was able to get it going:

line: 20 in dojo.js line: 82 in dojo.uncompresses.js

if((!this["console"])||(!console["firebug"])){
		this.console = {};
	}

	var cn = [
		"assert", "count", "debug", "dir", "dirxml", "error", "group",
		"groupEnd", "info", "log", "profile", "profileEnd", "time",
		"timeEnd", "trace", "warn"
	];
	var i=0, tn;
	while((tn=cn[i++])){
		if(!console[tn]){
			console[tn] = function(){};
		}
	}

you can contact me at mcoquet@… if you wish to.

Excellent work on the feature by the way :)

Cheers

Miguel Coquet

[jburke]

Miguel: Dojo 1.0 does not have the code to be scoped to a different namespace: it only supports being under the "dojo" namespace. Dojo 1.1 beta 1 or greater has the scoping to a different namespace support.