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

[Shane O'Sullivan]

I think the "gradually migrate" use case is definitely a very common
one - my company's client infrastructure is currently very dependent
on 0.4.3, and after our major release in a few weeks, we will begin to
upgrade to 1.x.  Having this functionality work for that case would be
extremely useful to us.

Since you are wrapping all calls to dojo.require() with a private
function defining the scope map, would it not also make sense to do
the same in the optional build step - for each JS file that can be
dojo.require'd, wrap it's contents in that private function.  Would
this not function just the same as dojo.require, and work also for
script includes?  It would also remove the need for easily breakable
regexs

Thanks

Shane

On 21/01/2008, James Burke <jburke at dojotoolkit.org> wrote:
> 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
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>