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

[James Burke]

On Jan 21, 2008 1:54 PM, Shane O'Sullivan <shaneosullivan1 at gmail.com> wrote:
> How does this work with <script> including files?  When I specify the
> scopemap from the trunk code, and include some dojox files, an error
> is thrown saying that dojox is not defined.  dojox10 is defined
> instead.
>
> So, does this only work if dojo10.require() is used?  Does that
> automatically replace references in 'dojox' with 'dojox10', or how
> does it work?

Yes, it breaks with script-included files. The scope mechanism works
by wrapping any code that is dojo.required in a function that defines
what dojo, dijit and dojox really are. For example, it does something
like this after fetching the module's source with XHR:

eval("(function(dojo, dijit, dojox){
   //Your module's code goes in here
})(dojo10, dijit10, dojox10);");

(the xdomain thing does something similar, but you have to know the
scope values at build time for anything beyond dojo, dijit and dojox)

This has the benefit that we don't have to do some sort of complex
regexp work at runtime or buildtime. I'm not confident we could catch
all the cases using regexps. And it means we can support scoping with
a default build of dojo (we do not have to make the scoping decision
at build time -- we can do it at runtime). However it does break
things if you are trying to manually import code via script tags.

I will be adding a feature to debugAtAllCosts where if you are using
the scoping stuff, it will create a globally visible dojo, dijit and
dojox and bind them to the dojo10, dijit10, dojox10 (for instance)
variables. This should then allow for doing the normal debugging you
get with inlined script tags.

*However*, the debugAtAllCosts global thing will make it hard if you
are trying to debug your scoped code with other code on the page that
is using dojo. At that point, I suggest doing a custom build of your
scoped code so that everything is in a built, scoped dojo.js and
proceed from there. That is what I consider the common workflow case
(at least in the future):

- You want to provide a library that uses dojo underneath, but you
want to scope it to a different name, say "foo", "fijit" and "fojox".
- You develop your library using the scope hooks, but you do not use a
custom build and at this point you are not mixing with other dojo
versions -- you are just developing your code. In this case you can
use the debugAtAllCosts flag to help in your debugging (after I do the
changes mentioned above).
- You get it working, then you do your custom build, and deliver your
foo.js for others to use.
- Other people can use your foo.js in a page with other dojo code. If
they need to debug, hopefully your foo.js is self contained, and the
debugAtAllCosts debugging will only affect the other dojo. There will
also be a build option to burn in a local djConfig so that your
library code does not get weird djConfig values from the other dojo.

For the other workflow where you have a Dojo 0.4.3 app and want to mix
in Dojo 1.1, then it will require more work -- most likely doing some
custom builds of  the scoped 1.1 so everything is in one dojo.js file
that you can import. Even though this use case is more work and
probably the more common case right now, I expect this use case to
shrink to zero with the other use case above being the majority case.

Hopefully that explains the tradeoffs and why I'm favoring the "make
your own library with dojo" case over the "gradually migrate my app
from 0.4.3 to 1.x" case. I'm happy to hear feedback though. I did this
work mostly in isolation, so I may have missed the mark for what we
want.

James