[dojo-contributors] Allow multiple dojo versions in a page for 1.1?

[Jared Jurkiewicz]

This will cause problems with dojo.data, I believe.  Specifically,
with third-party such as Flickr, which requires a loosely defined
function.  My area of concern is your statement of

> 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 fil
> attached directly via script elements.
>

Because things like FlickrStore have to set a global function.
Otherwise, the Flickr API tiself won't work.  What will the solution
for that be?   Can you test your proposed changes against the
dojox.data component?  (dojox/data/tests/runTests.html)

This sort of major change makes me really nervous.  This should be
discussed, I think, in the Wednesday weekly meetings before the
changes are just committed in.

Sincerely,
-- Jared Jurkiewicz


On Dec 30, 2007 12:29 PM, 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
>