Fix for RequireJS

[Lundgren]

There are two problems with the current support of AMD modules in DDT when it comes to RequireJs (and probably other module loaders as well). First all modules that are imported through script tags from an html page have to be named and second is that the code never run, its only added to modules.

One possible solution is to name each module (first parameter in define()) and to call the code (the require() in base.html). But this would only work for RequireJS and no other AMD loaders (to my knowledge at least).

Perhaps the best solution is just be to go back to browser global's? DDT is only used during development anyways.

[ebrelsford]

I'd love to have RequireJS support fixed, using DDT is difficult in the meantime.

[aaugustin]

I'm unable to assess this pull request with my limited frontend skills.

Is there a tutorial somewhere to educate myself?

I've tried to find my way through http://requirejs.org/ but there's lots of material in there and most of it is lost on me.

[Lundgren]

I'm not aware of any good simple tutorials to start with. But a good start
might be this which describes AMD modules and their alternatives:
http://requirejs.org/docs/whyamd.html

And here is about the naming error that occurs:
http://requirejs.org/docs/errors.html#mismatch

AMD loaders, such as RequireJS, works by registering a global function like
this:
define(id, dependencies, factory);

Each time anyone define a module by calling the define function the
loader stores away the factory method without executing it. Later when that
module is used (through another modules dependencies, through require()
or some other way) the factory method will be called once and the result
from that execution will be used every other time the module is used.

So the way DDT uses today works fine for a library like jquery-cookie that
people have to actively use it, then they can import it through a script
tag or through RequireJS. But not quite as good for DDT which I assume most
users just want to work passively without involving their JS code.

[djfarrelly]

Having this problem myself with upgrade to 1.0. The changes in this pull request fix the issue in an appropriate way. The alternative is to not use the UMD-inspired wrapper added here: acc0f84 and just use browser globals like mentioned in the PR.

I agree with @Lundgren that most users would want DDT to work passively and not using RequireJS to register the module. It seems no other DDT module is relying on toolbar.js's exported djdt object, so it wouldn't have to be added to the global scope and could just be used once within a self executing function. I think this is the cleanest approach.

To try to explain what @Lundgren said further, RequireJS keeps an internal registry of all modules it loads itself or registered via the define call. When a script is loaded via <script> tag and not by RequireJS's loader, it doesn't know what to register it as and throws the mismatch error. All RequireJS modules are registered in 1 of 3 ways: with an ID in it's define call, with an alias specified in require.config or when it's loaded asynchronously as a dependency and it's relative path is used (ex. static/js/someScript).

Basically RequireJS complains when it doesn't know how to register the module because then other modules can't consume it. The solution is to name it or remove the define call.

[aaugustin]

Variations of this issue have been reported several times. I'm moving the discussion to #535. Thanks for your understanding.