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

James Burke jburke at dojotoolkit.org
Mon May 4 14:02:07 EDT 2009


On Sun, May 3, 2009 at 10:27 PM, Greg Wilkins <gregw at mortbay.com> wrote:
>
> All,
>
> Simone has done some great work on the jquery implementation of cometd, which
> free from the ravages of evolution and changing ideas is a much cleaner implementation
> of the bayeux protocol that what is in dojox/cometd/*
>
> So Simone has done the work to abstract out a common js cometd.js for use
> by both dojo and jquery implementations (and eventually prototype, ext.js etc.)
>
> This work is checked into
>
>  https://svn.cometd.com/trunk/cometd-javascript
>
> and is roughly working for dojo already.
>
>
> However, other than some small API differences, there is a big packaging
> difference.  If you look at:
>
>  dojo/src/main/webapp/scripts/dojox/cometd/_base.js
>
> you see that is a dojo module that does a provide("dojox.cometd._base")
> but makes the assumption that cometd.js has previously been loaded,
> so you need to do
>
>    <script type="text/javascript" src="/dojo/dojo.js"></script>
>    <script type="text/javascript" src="/org/cometd.js"></script>
>    <script type="text/javascript">
>      dojo.require("dojox.cometd");
>    </script>
>
> the cometd.js creates a org.cometd object which is extended
> by dojox/cometd/_base.js  before doing a
>   dojox.cometd = new org.cometd.Cometd();
>
>
> Previously to use cometd in dojo, you would do something like:
>
>    <script type="text/javascript" src="/dojo/dojo.js"></script>
>    <script type="text/javascript">
>      dojo.require("dojox.cometd.longPollTransportJsonEncoded");
>      dojo.require("dojox.cometd.timestamp");
>      dojo.require("dojox.cometd.ack");
>    </script>
>
>
> Note that you can require a specific transport type and specific
> extensions.  With the common js approach, all transport types
> are loaded (pretty small) and it is yet to be determined if
> extensions will be in a separate file or not.
>
>
> What I'd like to be able to achieve is to avoid the need
> to separately source the cometd.js
> Looking at the source of loader.js, it appears that I should
> be able to pass true to omitModuleCheck and thus in _base.js do
> something like:
>
>   dojo.provide("dojox.cometd._base");
>   dojo.require("org.cometd.base",true);
>
> and that will load org/cometd/base.js and ignore that fact
> that it does not have a provides clause.   This would
> work just as well for extensions etc.
>
>
>
> So some questions (dumb and/or otherwise):
>
>
> Is this what omitModuleCheck is for?
> or should we just use dojo._loadPath directly ?
>
> Is there an equivalent load in jquery?
> or will multiple script src's be needed?
>
>
> Where should the common js be in the name hierarchy?
> is org.cometd.*   OK?
> should we use the openajax hub to avoid name clashes?
>
> Can anybody think of a way to directly use common js
> files like this, but to have the object created
> directly into dojox.cometd   or jquery.cometd  names?

I have not used the cometd modules directly, so I may be missing
something above. How I read the above: you have a new streamlined JS
module at org/cometd.js, and perhaps it obsoletes the dojox.cometd
stuff, or the dojox.cometd. stuff are just adapters on top of the
org/cometd.js module.

You are wondering how org/cometd.js can be loaded in Dojo without an
explicit script tag. For that case I normally suggest doing the
following:

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");
}

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.

I suggest not using dojo._loadPath directly or the variation of
dojo.require that passes true for omitModuleCheck. It makes it hard
for the dojo.addOnLoad() callbacks to work reliably if we do not check
for the the module being loaded. The typeof dojo check above in the
cometd.js should avoid the need for omitModuleCheck, and still allow
the file to work without dojo being loaded.

James


More information about the dojo-contributors mailing list