[dojo-contributors] Code style change (was Re: Allow multiple dojo versions in a page for 1.1?)

[James Burke]

I just committed a set of changes that allows multiple versions of
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 <jburke at dojotoolkit.org> 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
>