The module dojox.rpc.Client was introduced in Dojo Toolkit version 1.2, providing extra request headers on XMLHttpRequests to facilitate implementing deterministic request handling on servers. Browsers typically use two or more TCP connections to send HTTP requests to a server, while subsequent requests are often routed on separate TCP connections. This means there is no guarantee that the request that is sent first will arrive at the server first. With sophisticated web applications, non-determinism can lead to bugs that are very difficult to track down.
If a web application sends multiple requests to a server and assumes that the server will handle them in the order they were sent, this non-determinism can be problematic. Furthermore, messages that arrive out of order can be rare, and therefore problems can be hard to reproduce. On old modem connections, packets were sequenced over a slow PPP connection that made out of order messages almost non-existent. With modern broadband connections, the race becomes more interesting. HTTP pipelining adds another mechanism that can lead to messages arriving out of order and with browsers beginning to support and use pipelining, messages arriving out of order will become even more likely in the future.
Dijit has a tremendous wealth of high quality and feature-rich form elements providing key functionality including validation, time calculation, spinner controls, calendars, and much more. Furthermore, Dijit gives you a set of themes to choose from: Tundra, Soria, Noir, and Nihilo.
Silicon Valley Web Builder has a series of monthly panels on topics of interest to web application developers. I had the opportunity to attend a pair of events recently, once as a speaker, once as an attendee, and the contrast between the two was intriguing. The first panel in November was focused on Comet, while the most recent panel was a comparison of Ajax toolkits.
As an attendee of the Comet panel, I found the discussion interesting, but was a bit disheartening and negative. In retrospect, the negative tone reflects the pain and disappointment Comet engineers face in trying to come up with the perfect solution for low-latency data transit across the wire. Michael Carter was the lone optimist, describing the work he has done to date with Orbited, and what the HTML5 WebSocket promises to bring us in the near future. The other panelists were not as optimistic, having been burned by specifications not adopted and the ongoing frustrations with HTTP connection limits, proxy configurations, flaky internet connections, and more—all of which prevent many of the better approaches to Comet being viable.
From the perspective of a web designer with experience predominantly in HTML and CSS (the content and presentation layers), the behavior layer can seem a bit mystical. The behavior layer focuses on interactivity; unfortunately, it is a layer that can easily get lost, overlooked, or simply ignored in the collection of obligations that lay at the web designer’s feet—especially those who work for themselves, or who are within an organization as the sole “web person.” To all the multi-hatted, multi-tasked designers out there, this article is an introduction to Dojo, a JavaScript toolkit that makes adding oomph to the behavior layer (and so much more) really easy to do.
There are fundamental differences between the roles of application code and framework library modules within an application. Framework libraries provide reusable services that encapsulate lower-level functionality in an abstraction that offers functionality with an easy to use API for higher level code within a variety of different applications. Libraries generally stay static within the development of an application (besides the occasional upgrade). On the other hand, application code utilizes the functionality provided by library modules to create a specific behavior for the logical interaction between users and a domain of data in a generally tighter-defined environment. Application code is completely dynamic within the application development process, it is constantly changing as the application evolves and develops. Recognizing and facilitating these differences is key to intelligently structuring a framework, and is a key principle behind the structure of Persevere.
The new Dojo Search is now live. I worked on creating this with the goal of showing how much information there is out there about the Dojo Toolkit and supplying a way to aggregate that information in a central location. Now you can search all of Dojo’s Resources instead of dojotoolkit.org alone. Most of the time if you have a question, it’s already been asked and answered!
The Dojo community is large and there is a lot of great information spread out across the vastness of the web. The Dojo Toolkit has been around for a while and has undergone numerous additions and improvements since its inception. Unfortunately, some of the documentation and valuable data needed by users and enthusiasts is decentralized. Dojo Search is designed to help alleviate this problem.
As web applications, services and mashups evolve, a perennial problem begins to assert itself—the issue of authorization (or in layman’s terms, making sure both application and service know who you are). A number of different approaches have been developed; one such approach is the OAuth specification, which is designed as a fool-proof way of validating requests.
Because of the growing popularity of the OAuth protocol, we’ve added support for it to the Dojo Toolkit in the form of dojox.io.OAuth—which can be used to sign any request made with the Dojo Toolkit’s various Ajax methods, including XHR, IFrame and Script transports.
I’m excited to announce a new open source project created by SitePen and co-sponsored by Adobe: Queued. With Queued, you can manage your Netflix queue anytime, anywhere!
It’s no secret that we’re big fans of Dojo here. Since Adobe AIR provides a platform that integrates desktop features into the browser development model, it’s easy to see where our favorite JavaScript toolkit fits: it’s every bit the springboard in the AIR world as it is in the browser world. We designed Queued to show what the Dojo + AIR combo can do.
Have you ever needed to make a GET request containing a complex request only to find out that it exceeds the maximum length that a url can contain when url encoded? Usually URLs come nowhere near the 2k length on IE and certainly not on other browsers where the length limit is 4k. In most cases, switching to using a POST request without the associated payload limits solves the problem. However, POST requests do not get cached. While this is appropriate in most cases where you are sending a large request, in my work I’ve found several cases where I want to make a complex (long) request, but still retain the caching benefits of GET.
In the past I’ve always been able to resort to some alternative, such as splitting up the request into multiple XHR GETs, but in a current project of mine, the alternatives were ugly or had some other drawbacks. Without getting sidetracked in those details, for purposes of this article, we’ll assume there are valid cases for long GET requests and that is the situation we are in.
Performing frequent training courses has given SitePen a chance to learn new ways to improve our training approach. Some concepts in JavaScript can be trickier than others and as we interact with the classes, we’re able to develop fun explanations for these tricky concepts. I’d like to share one of the explanations I developed at a recent training course.
A common phrase that results from these training sessions is “I didn’t know JavaScript could do that.” The first time we hear it is usually after we’ve covered how to work with functions in JavaScript, when we start showing how JavaScript allows us to use functions (in an approach termed functional programming). We try to conclude each part of the course with code examples that incorporate everything from the section we’ve just covered. At the end of our section on functional programming, we have the following example:
