[dojo-contributors] Tentative agenda for today meeting

Ben Hockey neonstalwart at gmail.com
Wed Oct 3 11:47:02 EDT 2012

On Oct 3, 2012, at 10:23 AM, Richard Backhouse wrote:

> I can consider adding more code to the AST parsing section to find it. Does the dojo build handle this module correctly ?

if you consider that this module should never be loaded via an AMD loader and as such it never ends up as a dependency of another module and is never a layer then the dojo build handles this properly - it just minifies it (like any other js file) when you set the appropriate option for `optimize`.

> Why do you not think an id should be added ?

ids make modules less portable.  it goes against what we "preach" about AMD.  if you can just ignore that there is any call to define in this file and pretend it's just a plain (non-AMD) js file then that would be a better way to consider this file.  in fact, if we were to make any changes to this file, it should be to remove the call to define because it doesn't work when loaded that way.  as christophe said though, we wouldn't do this in a point release.

this file goes even further than other plain js files - it should never be loaded via an AMD loader.  non-AMD modules can typically be loaded via an AMD loader but a non-AMD module does not produce any value for the module - i.e. the script can be injected but without a call to define there are no exports.  the reason this file can't even be treated like that is because there is a timing issue with loading this file asynchronously so it MUST be loaded by a script tag BEFORE dojo.js so that it can load the CSS before it's needed - just look at any dojox/mobile test, they all do this because this is how it needs to be done.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20121003/9e17b37a/attachment.htm 

More information about the dojo-contributors mailing list