<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'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 "Dojo way" and didn'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"><<a href="mailto:rgill@altoviso.com">rgill@altoviso.com</a>></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'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's loader, but was too
busy at the time to engage the amd list. Here'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't find it presently (Bryan, maybe you can remind
us of the syntax you proposed).<br>
<br>
fwiw, I'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 'nother ball-o-worms. I'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>