[dojo-contributors] common cometd.js for dojo & jquery

Peter E Higgins dante at dojotoolkit.org
Tue May 5 16:28:36 EDT 2009


It is probably unintended, and I likely wouldn't _truly_ recommend it in
real life (we may end up changing this unsupported behavior) but making
it work with the build is as simple as:

// dojo.provide("some.module");

Regards,
Peter


James Burke wrote:
> 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()?
>>
>> dojo.provide("dojox.cometd");
>>
>> 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.
>
> James
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors
>
>   


-- 
Peter E Higgins
Dojo Project Lead : http://dojotoolkit.org 



More information about the dojo-contributors mailing list