[dojo-contributors] Tentative agenda for today meeting

Richard Backhouse backhous at us.ibm.com
Wed Oct 3 12:01:02 EDT 2012


Hypothetically if a developer referenced deviceTheme as an AMD module and
then wanted to produce a build that would load it and all its dependencies
would it work ?


                                                                                                                       
  From:       Ben Hockey <neonstalwart at gmail.com>                                                                      
                                                                                                                       
  To:         "dojo dev." <dojo-contributors at mail.dojotoolkit.org>,                                                    
                                                                                                                       
  Date:       10/03/2012 11:49 AM                                                                                      
                                                                                                                       
  Subject:    Re: [dojo-contributors] Tentative agenda for today meeting                                               
                                                                                                                       






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.

ben...
_______________________________________________
dojo-contributors mailing list
dojo-contributors at mail.dojotoolkit.org
http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20121003/31b38b2d/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20121003/31b38b2d/attachment-0002.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20121003/31b38b2d/attachment-0003.gif 


More information about the dojo-contributors mailing list