dojo in a page. As a result, there is a new style guide rule (I
updated the guide to reflect this):
When constructing string IDs or ID prefixes in the code, do not use
"dojo", "dijit" or "dojox" in the names. Because we now allow multiple
versions of dojo in a page, it is important you use _scopeName instead
(dojo._scopeName, dijit._scopeName, dojox._scopeName).
I tried to change the places where I thought this rule applied. Be
sure to check out the changeset below to see if your favorite module
has changed:
Core: http://trac.dojotoolkit.org/changeset/12008
Dijit: http://trac.dojotoolkit.org/changeset/12010
Dojox: http://trac.dojotoolkit.org/changeset/12011
There were some things that may be candidates for _scopeName, but I
was not sure. Just calling them out in case you want to review for
yourselves:
- dojox.dtl: some registration going on?
- dojox.wire _wireClasses?
- No dojox flash things were updated, since the .as files do not have
access to the _scopeName property.
- dojox/presentation/_base.js: getSiblingsByType. May be problematic?
I ran the Core unit tests in all the major browsers and ran the
dojox.data tests. I ran themeTester.html in IE 6. I think everything
is OK, but I could have missed something. Just holler if I did, and
I'll fix it asap.
If you are curious how to use this functionality, you can see the
source for test files that start with "scope" in this folder:
http://trac.dojotoolkit.org/browser/dojo/trunk/tests/_base/_loader
Once I clean up some loose ends (really just xdomain debugAtAllCosts
support) then I'll being doing some doc updates.
James
On Dec 30, 2007 9:29 AM, James Burke wrote:
I've been working on a change that would allow running more than one
version of Dojo in the page:
http://trac.dojotoolkit.org/ticket/4573
I will likely start applying the change in about a week, but it has
some coding implications. You may not feel the changes are worth the
added benefit. If so, please speak up now, and if it seems like we
generally do not like the tradeoffs, then I will not do the code
changes.
Benefits:
==============
1) Allows someone that provides a JS library to use dojo underneath
the covers, but that version of Dojo would not interfere with another
version used on the page. It also means that other version on the page
will not interfere with the version used by the JS library. Example:
Mapquest could use some of Dojo's gfx code to help with doing map
drawings, and this code could be used in many different sites which
may use different versions of Dojo (disclaimer: Mapquest is owned by
AOL, I work for AOL. I have not talked with the Mapquest team about
this, so I do not know if they need this capability, I am
extrapolating).
2) Might allow easier code migration to 1.x from 0.4.
3) The code changes will work for modules outside of the blessed dojo
modules. There is some special consideration in xdomain builds (you
have to know all the 3rd party module prefixes you are going to use up
front before you do the xdomain build), but otherwise you can multiple
versions of your own modules in a page.
Code impact:
==============
1) Some of the code uses "dojo" or "dijit" for node names or IDs. That
code would be changed to use dojo._scopeName and dijit._scopeName.
After this code change, you will need to make sure you use the new
_scopeName properties when making strings that are based on the module
name. Note that css class names would not change. I figure it is
easier for people to wrap the code in a container element and apply a
unique class/ID on that container to get different styles (similar to
how we allow for multiple themes in a page).
2) You do not have to change how you reference dojo, dijit or dojox in
your code. The code works by enclosing loaded module resources in an
anonymous function that sets the dojo, dijit, dojox (and your own
custom prefixes). However, this means that dojo will never support
defining a loose function in a module and have it bind to the window
object. For instance defining:
function foo() { /*do something*/ }
in your module file means that it will not be visible as window.foo.
This limitation is already there for xdomain builds and for IE with
the normal dojo loader, but this change will now make this limitation
uniform. I think this is good, since dojo's behavior will always be
uniform and it encourages proper namespacing of code, but it can cause
issues for people assuming module files work just like normal files
attached directly via script elements.
3) I want to copy the djConfig object inside the dojo object. This
will allow multiple versions to change the djConfig object with
minimal effect on other versions that may want different djConfig
settings. This means in the future instead of referencing djConfig
directly, you would reference dojo.config or dojo.cfg or something
like that.
4) After I do this change you will have to be very careful about doing
code merges to and from the 1.0 branch (I think trunk is starting to
drift away from the 1.0 tree though, so you probably should be careful
anyway).
Example
=============
I have an example page working here:
http://dojotoolkit.org/~jburke/scope/dojo/tests/_base/_loader/scope04.html
One additional thing I want to add to what is working in the test page
is the ability to do dojo10.require("dojo10.parser"). I still want to
support dojo10.require("dojo.parser") too (it works and loads the
right version already), but I think being able to specify
"dojo10.parser" might make it clearer for the developer working with a
specific scope name.
Also, I'm using names like scopeMap and scopeName for setting up this
new capability. Holler if you think these are bad names.
I'll start the code changes in about a week, unless there is feedback
to the contrary.
James
I've been working on a change that would allow running more than one
version of Dojo in the page:
http://trac.dojotoolkit.org/ticket/4573
I will likely start applying the change in about a week, but it has
some coding implications. You may not feel the changes are worth the
added benefit. If so, please speak up now, and if it seems like we
generally do not like the tradeoffs, then I will not do the code
changes.
Benefits:
==============
1) Allows someone that provides a JS library to use dojo underneath
the covers, but that version of Dojo would not interfere with another
version used on the page. It also means that other version on the page
will not interfere with the version used by the JS library. Example:
Mapquest could use some of Dojo's gfx code to help with doing map
drawings, and this code could be used in many different sites which
may use different versions of Dojo (disclaimer: Mapquest is owned by
AOL, I work for AOL. I have not talked with the Mapquest team about
this, so I do not know if they need this capability, I am
extrapolating).
2) Might allow easier code migration to 1.x from 0.4.
3) The code changes will work for modules outside of the blessed dojo
modules. There is some special consideration in xdomain builds (you
have to know all the 3rd party module prefixes you are going to use up
front before you do the xdomain build), but otherwise you can multiple
versions of your own modules in a page.
Code impact:
==============
1) Some of the code uses "dojo" or "dijit" for node names or IDs. That
code would be changed to use dojo._scopeName and dijit._scopeName.
After this code change, you will need to make sure you use the new
_scopeName properties when making strings that are based on the module
name. Note that css class names would not change. I figure it is
easier for people to wrap the code in a container element and apply a
unique class/ID on that container to get different styles (similar to
how we allow for multiple themes in a page).
2) You do not have to change how you reference dojo, dijit or dojox in
your code. The code works by enclosing loaded module resources in an
anonymous function that sets the dojo, dijit, dojox (and your own
custom prefixes). However, this means that dojo will never support
defining a loose function in a module and have it bind to the window
object. For instance defining:
function foo() { /*do something*/ }
in your module file means that it will not be visible as window.foo.
This limitation is already there for xdomain builds and for IE with
the normal dojo loader, but this change will now make this limitation
uniform. I think this is good, since dojo's behavior will always be
uniform and it encourages proper namespacing of code, but it can cause
issues for people assuming module files work just like normal files
attached directly via script elements.
3) I want to copy the djConfig object inside the dojo object. This
will allow multiple versions to change the djConfig object with
minimal effect on other versions that may want different djConfig
settings. This means in the future instead of referencing djConfig
directly, you would reference dojo.config or dojo.cfg or something
like that.
4) After I do this change you will have to be very careful about doing
code merges to and from the 1.0 branch (I think trunk is starting to
drift away from the 1.0 tree though, so you probably should be careful
anyway).
Example
=============
I have an example page working here:
http://dojotoolkit.org/~jburke/scope/dojo/tests/_base/_loader/scope04.html
One additional thing I want to add to what is working in the test page
is the ability to do dojo10.require("dojo10.parser"). I still want to
support dojo10.require("dojo.parser") too (it works and loads the
right version already), but I think being able to specify
"dojo10.parser" might make it clearer for the developer working with a
specific scope name.
Also, I'm using names like scopeMap and scopeName for setting up this
new capability. Holler if you think these are bad names.
I'll start the code changes in about a week, unless there is feedback
to the contrary.
James
