<font color="#003333"><font><font face="verdana,sans-serif">Ah, I was missing something.</font></font></font><div><font color="#003333"><font><font face="verdana,sans-serif"><br></font></font></font></div><div><font color="#003333"><font><font face="verdana,sans-serif">I will edit dojo.require() in the docs to reference the AMD page.  This was the piece of documentation I was missing, because reading the source code, while insightful, wasn&#39;t the easiest thing to get my head wrapped around.</font></font></font></div>
<div><font color="#003333"><font><font face="verdana,sans-serif"><br></font></font></font></div><div><font color="#003333"><font><font face="verdana,sans-serif">My main reason for asking for it was because I was thinking in the &quot;Dojo way&quot; and didn&#39;t fully appreciate/remember that we need to keep parity with the AMD specification.</font></font></font></div>
<div><font color="#003333"><font><font face="verdana,sans-serif"><br></font></font></font></div><div><font color="#003333"><font><font face="verdana,sans-serif">Thanks!<br></font></font></font><br><div class="gmail_quote">
On 31 December 2011 21:00, Rawld <span dir="ltr">&lt;<a href="mailto:rgill@altoviso.com">rgill@altoviso.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<u></u>

  
    
  
  <div text="#000000" bgcolor="#ffffff"><div class="im">In the example you show, I don&#39;t understand how the non-error code
    path of a deferred is any different than the callback from a
    require.</div>
    <br>
    The error-code path is another matter entirely. imo, the amd spec
    (as it exists today) does not address error recovery rationally. I
    made some attempt to put some hooks into dojo&#39;s loader, but was too
    busy at the time to engage the amd list. Here&#39;s what is there:<br>
    <br>
    <a href="http://livedocs.dojotoolkit.org/loader/amd#error-reporting" target="_blank">http://livedocs.dojotoolkit.org/loader/amd#error-reporting</a><br>
    <br>
    There is a use  case for returning deferreds where you want to load
    module x, which (in general) has a *run-time* dependency on one
    module in {x1, ..., xn}. That run-time dependency computation may
    itself require modules to be loaded. This can be handled with a
    plugin. An example is found in dojox/gfx. I suspect this is the real
    heart of the matter with the parser, so a plugin may also be the
    answer there.<br>
    <br>
    Bryan Forbes had a nice way to express and asynchronous-asynchronous
    module load...can&#39;t find it presently (Bryan, maybe you can remind
    us of the syntax you proposed).<br>
    <br>
    fwiw, I&#39;m also happy to consider trying out new loader features. I
    constructed the loader so it would be easy to include/exclude
    features at run-time/build-time. Getting the amd implementers to
    agree is a whole &#39;nother ball-o-worms. I&#39;ll help argue, but if you
    want it to be part of the quasi-official spec, join <a href="https://groups.google.com/group/amd-implement" target="_blank">https://groups.google.com/group/amd-implement</a>
    and be prepared to be exhausted.<br>
    <br>
    --Rawld<br>
    <br><br></div></blockquote></div></div>