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

Adam Peller peller at gmail.com
Tue May 5 10:08:46 EDT 2009

If this stuff is ultimately going to live somewhere else, I don't see
any need to maintain a dojox home for cometd in the long-term.  People
should be encouraged to use it from its new home unless we're adding
some value -- do you see there being anything additional that
dojox.cometd would offer?  We do have a little bit of a problem since
dojox.cometd is marked as 'beta', however.


On Tue, May 5, 2009 at 3:13 AM, Peter E Higgins <dante at dojotoolkit.org> wrote:
> What is wrong with maintaining is as if it were like sizzle? The real
> thing needed here is a dojo.provide() call, and perhaps a dojox.cometd =
> org.cometd; in the footer. Why can't Dojo "maintain" it's own dojox
> cometd from an external repo. The cometd and dojo projects are under the
> same CLA's no? We could just add the two required lines and leave in
> DojoX as "the Dojo port", and allow all the other libraries to include
> their own packaging in their own versions. Patches could be applied if
> the only natural diff was the two lines and we get to keep the module on
> the CDN's.
> Regards,
> Peter
> James Burke wrote:
>> 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
>> dojo.io.script.get({
>>     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.
>> 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
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at mail.dojotoolkit.org
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-contributors

More information about the dojo-contributors mailing list