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

Sat Jan 12 15:14:21 UTC 2008

A 1.1 version can coexist with 0.4+ (as long as there is a
djConfig.scopeMap). One of the tests demonstrates 0.4 and 1.1
coexistence:

http://trac.dojotoolkit.org/browser/dojo/trunk/tests/_base/_loader/scope04.html

James

On Jan 12, 2008 12:51 AM, Michael Smith <savoyboy at gmail.com> wrote:
> This looks great. Does this mean that 1.1 will be able to coexist with
> 0.4.x, 0.9, or 1.0 versions? Or is this only effective for multiple versions
> that are 1.1+?
>
> Thanks for the good work.
> ~Michael
>
>
>
>
>  On Jan 11, 2008 7:36 PM, James Burke <jburke at dojotoolkit.org> wrote:
> >
> >
> >
> > 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
> > >
> > _______________________________________________
> > dojo-contributors mailing list
> > dojo-contributors at dojotoolkit.org
> > http://dojotoolkit.org/mailman/listinfo/dojo-contributors
> >
>
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
>