headers
Mike Wilson | 3 May 2009 18:13
Picon
Favicon

dojo book

I noticed that the "Book of Dojo 1.3" link on 
dojotoolkit.org now goes straight to dojocampus.

Is it really wise to deprecate the Book this early, before
dojocampus has matured more? The Book is IMO the best 
documentation effort done so far for Dojo and have helped
improve its documentation reputation a lot. While 
respecting the effort being put into dojocampus, it still
gives a half-finished feeling and doesn't come close to 
the Book in structural and navigational experience.

Wouldn't it be better to put some effort into updating the
Book for 1.3, keeping dojocampus as an additional resource
until it has matured both content- and structure-wise?

Best regards
Mike Wilson
Permalink | Reply | 0 comments |
headers
Greg Wilkins | 4 May 2009 07:27
Gravatar

common cometd.js for dojo & jquery


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>
(Continue reading)

Permalink | Reply | 19 comments |
headers
James Burke | 4 May 2009 20:02
Favicon

Re: common cometd.js for dojo & jquery

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">
(Continue reading)

Permalink | Reply | 16 comments |
headers
Greg Wilkins | 5 May 2009 06:34
Gravatar

Re: common cometd.js for dojo & jquery

James Burke wrote:

> 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.

this is correct.

it is intended to replace the implementation that is currently
checked into dojox.

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

while that would work, it's not that extensible.
We might end up with similar code for jquery, prototype,
ext.js etc. etc.

> 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" }.
(Continue reading)

Permalink | Reply | 15 comments |
headers
James Burke | 5 May 2009 06:57
Favicon

Re: common cometd.js for dojo & jquery

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().
(Continue reading)

Permalink | Reply | 14 comments |
headers
Peter E Higgins | 5 May 2009 09:13
Favicon
Gravatar

Re: common cometd.js for dojo & jquery

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
(Continue reading)

Permalink | Reply | 13 comments |
headers
Adam Peller | 5 May 2009 16:08
Picon

Re: common cometd.js for dojo & jquery

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.

-Adam

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"){
(Continue reading)

Permalink | Reply | 6 comments |
headers
Nathan Toone | 5 May 2009 16:16
Favicon
Gravatar

Re: common cometd.js for dojo & jquery

I think that the value we'd be adding would be the ability to include  
it via the standard "dojo.require" calls - and to be able to include  
it in a build (I'm guessing).

-Nathan

On May 5, 2009, at 8:08 AM, Adam Peller wrote:

> 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.
>
> -Adam
>
> 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
(Continue reading)

Permalink | Reply | 5 comments |
headers
Peter E Higgins | 5 May 2009 16:18
Favicon
Gravatar

Re: common cometd.js for dojo & jquery

.. and the CDN. One can use Cometd in conjunction with a CDN hosted
Dojo, but this would require extra-special-local-namespace and mixed
location setttings.

Regards,
Peter

Nathan Toone wrote:
> I think that the value we'd be adding would be the ability to include
> it via the standard "dojo.require" calls - and to be able to include
> it in a build (I'm guessing).
>
> -Nathan
>
> On May 5, 2009, at 8:08 AM, Adam Peller wrote:
>
>> 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.
>>
>> -Adam
>>
>> 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 =
(Continue reading)

Permalink | Reply | 4 comments |
headers
Dustin Machi | 5 May 2009 16:32
Favicon
Gravatar

Re: common cometd.js for dojo & jquery

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

I haven't tested that, but as i understand it the second param is the  
omitModuleCheck and the require() actually returns the module.  Also  
even with omitModuleCheck, if the module is loaded, it still uses the  
already loaded one, so it wouldn't load it a second time in any case.   
The only change that would be needed is to store a module in  
dojo._loadedModules[moduleName] when it is retrieved even with  
omitModuleCheck...it just shouldn't error in that case.

So this code:

// check that the symbol was defined
		// Don't bother if we're doing xdomain (asynchronous) loading.
		if(!omitModuleCheck && !this._isXDomain){
			// pass in false so we can give better error
			module = this._loadedModules[moduleName];
			if(!module){
				throw new Error("symbol '" + moduleName + "' is not defined after  
loading '" + relpath + "'");
			}
		}

could be changed to:
(Continue reading)

Permalink | Reply | 3 comments |

Gmane