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

James Burke jburke at dojotoolkit.org
Tue May 5 00:57:27 EDT 2009

On Mon, May 4, 2009 at 9:34 PM, Greg Wilkins <gregw at mortbay.com> wrote:
> James Burke wrote:
>> 1) In org/cometd.js, have a block near the top of the file with something like:
>> if(typeof dojo != "undefined"){
>>     dojo.provide("org.cometd");
>> }
> while that would work, it's not that extensible.
> We might end up with similar code for jquery, prototype,
> ext.js etc. etc

That is doubtful: very few (none that I know of) have a module loader
like Dojo's. YUI has something, but you specify all the dependencies
outside of the actual files. But maybe it is a concern for the future.
If you want to avoid the dojo references, as of Dojo 1.4 (the current
trunk code in dojo), you can load the module via

    url: "path/to/org/cometd.js",
    load: function(){
        //Do something when the file is loaded.

Note that only works with the latest dojo.io.script. Any version from
1.3.x or earlier will not work. It also does not tie into the module
loader, so you would have to wrap the code above in a
dojo.addOnLoad(function(){}) block if you want to do the work done
near page load, and any cometd stuff would have to be set up in that
load: callback from dojo.io.script.get().

It also makes it hard to include the module as part of a custom build
-- the developer would have to throw in that typeof dojo/dojo.provide
block in order to use it in a custom build.

>> 2) For users of dojox.cometd, instruct them where to download the
>> org/cometd module and to either place the org directory as a sibling
>> to dojox or configure the path to org/cometd.js via
>> djConfig.modulePaths = { "org.cometd", "path/to/org/cometd" }.
>> dojo.setModulePath() could also be used instead of
>> djConfig.modulePaths (but after dojo is loaded). Notice for the path
>> to the cometd.js file, in modulePaths, I left off the ".js" part of
>> the name. The module mapping in Dojo allows you to specify a
>> modulePath for a directory, or in this case, a specific module, but
>> just leave off the .js extension for a specific module.
> Well here is the other problem... currently cometd-dojox is
> checked into dojox as part of the whole dojo tree and it is
> released with dojo.
> Perhaps it would be better to split this out of dojox
> so that to code resided and was released from org.cometd
> this would mean that it would be excluded from the dojo
> build system and could not be wrapped up into a custom
> built js.
> This is more than a technical question.   It is really
> about if dojox modules will ever have lifecycles of their
> own.

There is a desire to have dojox subprojects on their own release
cycles, but that will take a bit of work to set up by the dojox folks.
I think it is perfectly fine for the module to not live in dojox and
be available from another location. It was nice to have the code under
the Dojo-approved licenses/CLA process, but looks like the module is
under Apache which has similar rules.

One downside of it not being in dojox means at least right now (since
dojox releases are not broken out), dojox modules get up on the
Google/AOL CDNs which make for easy use/distribution.


More information about the dojo-contributors mailing list