Tag: dojo

CometD, Dojo and XDomainRequest
The CometD project implements various Comet techniques to implement a web messaging bus.
You can find an introduction to CometD here.
Web applications often need to access resources residing on different servers, making the request to access those resources a cross origin request and therefore subject to the same origin policy.
Fortunately, all modern browsers implement the Cross Origin Resource Sharing (CORS) specification, and with the support of Jetty‘s Cross Origin Filter, it’s a breeze to write applications that allow cross origin resource sharing.
That is, all modern browsers apart Internet Explorer 8 and 9.
Without CORS support, CometD fallbacks to another Comet technique known as JSONP.
While JSONP is much less efficient than a CORS request, it guarantees the CometD functionality, but it’s 2011 and JSONP should be a relic of the past.
Microsoft’s browsers have another JavaScript object that allows to make cross origin request: XDomainRequest.
Unfortunately this object is non-standard, and it is not, in general, supported by the JavaScript toolkits on which CometD relies for the actual communication with the server.
I cannot really blame toolkits authors for this lack of support.
However, I recently found a way to make XDomain request work with CometD 2.4.0 and the Dojo toolkit library.
The solution (see this blog post for reference) is the following:
Add this code to your JavaScript application:
```
dojo.require("dojox.io.xhrPlugins");
...
dojox.io.xhrPlugins.addCrossSiteXhr("http://<crossOriginHost>:<crossOriginPort>");
```
What remains is to configure CometD with the crossOriginHost:
```
dojox.cometd.configure({
    url: "http://<crossOriginHost>:<crossOriginPort>"
});
```
The last glitch is that XDomainRequest does not seem to allow to send the Content-Type HTTP header, so all of the above will only work in CometD 2.4.0.RC1 or greater where this improvement has been made.
I do not particularly recommend this hack, but sometimes it’s the only way to support cross origin requests for the obsolete Internet Explorers.
07/11/2011
CometD Introduction
The CometD project provides tools to write server-side event-driven web applications.
This kind of web application is becoming more popular, thanks to the fact that browsers have become truly powerful (JavaScript performance problems are now a relic of the past) and are widely deployed, so they are a very good platform for no-install applications.
Point to the URL, done.
Server-side event-driven web applications are those web application that receive events from third party systems on server side, and need to delivery those events with a very low latency to clients (mostly browsers).
Examples of such applications are chat applications, monitoring consoles, financial applications that provide stock quotes, online collaboration tools (e.g. document writing, code review), online games (e.g. chess, poker), social network applications, latest news information, mail applications, messaging applications, etc.
The key point of these applications is low latency: you cannot play a one-minute chess game if your application polls the chess server every 5-10 seconds to download your opponent’s moves.
These applications can be written using Comet techniques, but the moment you think it’s simple using those techniques, you’ll be faced with browsers glitches, nasty race conditions, scalability issues and in general with the complexity of asynchronous, multi-threaded programming.
For example, Comet techniques do not specify how to identify a specific client. How can browserA tell the server to send a message to browserB ?
It soon turns out that you need some sort of client identifier, and perhaps you want to support multiple clients in the same browser (so no, the HTTP session is not enough).
Add to that connection heartbeats, error detection, authentication and disconnection and other features, and you realize you are building a protocol on top of HTTP.
And this is where the CometD project comes to a rescue, providing that protocol on top of HTTP (the Bayeux protocol), and easy-to-use libraries that shield developers from said complexities.
In a nutshell, CometD enables publish/subscribe web messaging: it makes possible to send a message from a browser to another browser (or to several other browsers), or to send a message to the server only, or have the server send messages to a browser (or to several other browsers).
Below you can find an example of the JavaScript API, used in conjunction with the Dojo Toolkit:
```
  
    
    
  
```
You can subscribe to a channel, that represents the topic for which you want to receive messages.
For example, a stock quote web application may publish quote updates for Google to channel /stock/GOOG on server-side, and all browsers that subscribed to that channel will receive the message with the updated stock quote (and whatever other information the application puts in the message):
```
dojox.cometd.subscribe("/stock/GOOG", function(message)
{
  // Update the DOM with the content from the message
});
```
Equally easy is to publish messages to the server on a particular channel:
```
dojox.cometd.publish("/game/chess/12345", {
  move: "e4"
});
```
And at the end, you can disconnect:
```
dojox.cometd.disconnect();
```
You can have more information on the CometD site, and on the documentation section.
You can have a skeleton CometD project setup in seconds using Maven archetypes, as explained in the CometD primer. The Maven archetypes support Dojo, jQuery and (optionally) integrate with Spring.
Download and try out the latest CometD 2.1.1 release.
07/04/2011
CometD 2.1.1 Released

CometD 2.1.1 has been released.
This is a minor bug fix release that updates the JavaScript toolkits to Dojo 1.6.0 and jQuery 1.5.1, and Jetty to 7.3.1 and 6.1.26.
Enjoy !

07/04/2011
CometD 1.1.4 Released

CometD 1.1.4 has been released.
This is a minor release that updates the JavaScript toolkits to Dojo 1.6.0 and jQuery 1.5.1, and Jetty to 7.3.1 and 6.1.26.
Enjoy !

28/03/2011