#4573 closed defect (fixed)
avoiding dojo namespace collision between 1.0 and 0.4
Reported by: | guest | Owned by: | James Burke |
---|---|---|---|
Priority: | high | Milestone: | 1.1 |
Component: | Core | Version: | 0.9 |
Keywords: | Cc: | alex | |
Blocked By: | Blocking: |
Description
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...
Attachments (7)
Change History (30)
comment:1 Changed 13 years ago by
Component: | design/interactions → Core |
---|---|
Milestone: | → 1.0 |
Owner: | changed from torrey to alex |
Version: | 1.0 → 0.9 |
comment:2 Changed 13 years ago by
comment:3 Changed 13 years ago by
Owner: | changed from alex to James Burke |
---|---|
Status: | new → assigned |
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.
comment:4 Changed 13 years ago by
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
comment:5 Changed 13 years ago by
Cc: | alex added |
---|
this looks great. I'll give the patches a look tonight.
Changed 13 years ago by
Attachment: | buildscripts.patch added |
---|
Patch for util/buildscripts, done against r11084
Changed 13 years ago by
Attachment: | dojo.2.patch added |
---|
Patch for dojo core repo, done against r11084
Changed 13 years ago by
Attachment: | scope04.html added |
---|
Test file showing Dojo 0.4.3 and Dojo "1.0" loading in the same page, with widget parsing.
Changed 13 years ago by
Attachment: | scopeContained.html added |
---|
Test file showing Dojo 0.4.3 and jodo, a scope defined within a built dojo.js file.
Changed 13 years ago by
Attachment: | scopeContainedXd.html added |
---|
XDomain test file showing Dojo 0.4.3 and jodo, a scope defined within a built dojo.js file.
comment:6 Changed 13 years ago by
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.
Changed 13 years ago by
Attachment: | dojoGuardStart.jsfrag added |
---|
util/buildscripts/jslib/dojoGuardStart.jsfrag did not come through the patch file. Explicitly including it here.
Changed 13 years ago by
Attachment: | dojoGuardEnd.jsfrag added |
---|
util/buildscripts/jslib/dojoGuardEnd.jsfrag did not come through the patch file. Explicitly including it here.
comment:7 Changed 13 years ago by
NOTE: Be sure to scrub iframe_history.html: It tries to grab the parent frame's "dojo" global object. Need to make it smarter.
comment:8 Changed 13 years ago by
Milestone: | 1.0 → 1.1 |
---|
Pushing to 1.1. Not comfortable with this level of change so close to the 1.0 release.
comment:9 Changed 13 years ago by
comment:10 Changed 13 years ago by
comment:11 Changed 13 years ago by
comment:12 Changed 13 years ago by
comment:13 Changed 13 years ago by
comment:14 Changed 13 years ago by
comment:15 Changed 13 years ago by
comment:16 Changed 13 years ago by
comment:17 Changed 13 years ago by
comment:18 Changed 13 years ago by
comment:19 Changed 13 years ago by
comment:20 Changed 13 years ago by
comment:21 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:22 Changed 13 years ago by
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 [email protected]… if you wish to.
Excellent work on the feature by the way :)
Cheers
Miguel Coquet
comment:23 Changed 13 years ago by
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.
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?