[dojo-contributors] common cometd.js for dojo & jquery
jburke at dojotoolkit.org
Tue May 5 12:42:07 EDT 2009
On Tue, May 5, 2009 at 7:32 AM, Dustin Machi <dmachi at dojotoolkit.org> wrote:
> Maybe its backwards? Maybe dojox.cometd could just import the org
> implemenation using the second parameter to dojo.require()?
> dojox.cometd = dojo.require("org.cometd", true);
This has the same downsides as the dojo.io.script.get() path: the
module does not participate in the loader module tracking, so if you
have dojo.addOnLoad() code that requires the module to be loaded it,
the addOnLoad callback may fire before the module is loaded (in the
xdomain case). I guess it has one advantage over dojo.io.script in the
normal loader case, since it will be synchronously loaded. I have not
tested it, but there may be an issue with the xdomain loader properly
handling the module though -- I think I assume at least one
dojo.provide in the module. So use at your own risk.
I generally think the dojo.require("name", true) syntax to be
problematic. I probably would remove it in a Dojo 2.0 scenario.
If cometd.js just wants to be another JS file, then you have to use a
script tag to load it. I like the dojo loader and the benefits of
being able to dynamically load modules via dojo.require(), but if the
code maintainer prefers not to opt in to the benefits via a
dojo.provide, that is fine, and within their rights to do so. Dojo
will still be able to use the code, the code just has to be loaded
into the page via a script tag.
I think it still might work in a custom build scenario, something to
try for sure, but it may just include the code in the custom layer.
However it will not have the redefinition code guards around it (based
on looking for a dojo.provide call) so if you load another JS file
that has that module code in it, that second one will overwrite the
state created by the first one.
More information about the dojo-contributors