As was illustrated with our Dive Into Dijit post, the Dijit library provides an extremely powerful, flexible set of Dojo-based widgets with which you may easily enhance the look and functionality of your web application.  These widgets include drop down / popup menus, dialogs, page layouts, trees, progress bars, and form elements.  When looking at these elements, it’s easy to see that Dijit enhances their presentation but this post will focus on enhancing functionality;  specifically, enhancing a basic form with usability improvements and validation.

Quick Dijit Implementation Review

The first step in introducing Dijit to any page is including Dojo:

The next step is requesting the Dijit theme stylesheet:

The last step is adding the theme name as a class for the BODY element:

Enhancing Basic Form Elements

Note: this tutorial will use the declarative method of widget creation. You may create any Dijit widget programatically using dojo.behavior as described in Dive Into Dijit.

The first step in enhancing our static form is enhancing the form elements themselves.  Dijit provides a corresponding widget (sometimes two or three) for the different types of form elements. Using the declarative method of Dijit widget creation and the dojoType attribute, we’ll quickly widget-ize every piece of our static form:

Boom: our static, boring form elements have been themed and extended with extra functionality. A few notes with regard to widgets we created above:

• The FilteringSelect widget duplicates the functionality of a native SELECT element by:
  • Setting an initial value based on one of its options having a selected attribute.
  • Enforcing a fixed set of possible results based upon the values and text of each OPTION element.
  • Providing keyboard accessibility
• The FilteringSelect widget adds the following functionality to the basic SELECT element:
  • You may type values into the FilteringSelect; autocomplete is employed.
  • If an invalid value is provided, an error message is provided to the user.
  • You get more control over the display when the widget is disabled.
• Dojo 1.5 introduces strategies for employing placeholder text within INPUT elements to save you time in adding focus/blur events to accomplish the same functionality.

Now that the basic form has been widget-ized and themed, we can add basic validation functionality.

Form Validation with Dojo

As with just about every client-side problem, Dojo’s got a great solution for form validation. Luckily there are only a few key components required for basic form validation.

dijit.form.ValidationTextBox

A precursor to the overall validation of a form is deciding which elements are required. Say we want to require the first field; the dojoType of that will will change from dijit.form.TextBox to dijit.form.ValidationTextBox:

Since required="true" has been added to the widget, an error icon and tooltip (with error message) will display if the user fails to place text into the box. A custom error message can be placed within the missingMessage attribute, otherwise a generic message will display.

What if the field requires special validation of the pattern of input? That’s where the regExp attribute comes in:

Not only is the website field now required but the value of the field must pass the regular expression test provided by the regExp attribute.

Validation Utilities with dojox.validate

The dojox.validate library includes numerous utility functions and regular expressions for validating form element values. These utility functions can validate email addresses, URLs, phone numbers, ZIP codes, and much more. An example usage of dojox.validate with a ValidationTextBox would look like:

The validator attribute is a link to the validation function for emails. dojox.validate is especially helpful if you don’t feel comfortable with regular expressions. There are also locale-specific packages within dojox.validate. The API docs provide a complete listing of dojox.validate helpers.

dijit.form.Form with the onSubmit Event

Now that our required fields are in place, we’ll enhance the wrapping form element with a dijit.form.Form dojoType:

Accompanying the dijit.form.Form is a special script element. Within this Dojo-specific script is a this.validate() test, acting on the dijit.form.Form instance, which validates the entire form based on require="true" inputs. You could also add your own custom validation within the code block as well.

The dijit.form Collection

I’ve only touched the most-used Dijit widgets within my example above. There are several more outstanding form widgets within Dijit; let’s take a look at a few other helpful widgets!

DateTextBox

Asking the user to format a date properly can be a nightmare, especially if other form fields within the page rely on the contents of a given date field. Dijit provides a dijit.form.DateTextBox class which displays a user-friendly calendar widget for users to select a date on.

CurrencyTextBox

The dijit.form.CurrencyTextBox class helps the user to properly format and validate currency per a given locale.

Textarea

The dojox.form.Textarea class enhances a given TEXTAREA element so that the element grows in height as the user types.

Enhancing Basic Dijit Widgets with DojoX Alternatives

As nice as many of the Dijit widgets are, DojoX hosts numerous enhanced widgets that solve problems that many basic widgets cannot. The following are a few notable DojoX form widgets.

BusyButton

dijit.form.Button works great but what if I want to disable the button (to avoid double submissions) and provide a feedback message (i.e. “Sending form….”) when clicked? We could use dojox.form.BusyButton to do just that:

CheckedMultiSelect

What if our SELECT element allows for multiple selections? That’s the perfect opportunity to use the dojox.form.CheckedMultiSelect widget:

PasswordValidator

What if our website features a form that allows updating/changing of passwords? The dojox.form.PasswordValidator provides all the functionality you need to quickly implement that system:

Reminder: JavaScript validation is not a substitute for server-side validation; JavaScript simply enhances the user experience by providing instant feedback to the user.

FileUploader

File uploading without enhancement is probably the worst form control available. The dojox.form.FileUploader provides a great solution for making the process more streamlined:

The dojox.form Collection

The dojox.form namespace hosts a huge host of widget enhancements, including:

• BusyButton – button with special disable/busy label states
• CheckedMultiSelect – turns your SELECT element with the “multiple” attribute into a series of checkboxes for usability
• DropDownStack – disable/enable form elements based upon a selection
• RangeSlider – allows values to be chosen via a sliding scale
• Rating – easily creates UI for ratings (star ratings)
• …and much more!™

Great Dijit & Dojox Resources

• View Working Example
• Dijit Theme Tester
• Dive Into Dijit
• DojoX Form Reference Guide
• Dijit Form Reference Guide
• dojox.validate Reference

The Dijit library is much more than just gloss on your elements — it’s a hugely functional set of classes to make life easier for both you, the developer, and your users.

Related posts:

1. Dive Into Dijit
2. Dijit: Prepackaged
3. Styling Dijit Form Elements

Setting Up Your Namespace

All of Dojo’s charting themes live with in the dojox.charting.themes namespace. As is the best practice with custom class creation with Dojo, we’ll create our own namespace for our custom chart themes. Let’s give our custom theme the davidwalsh.charting.themes namespace. davidwalsh serves as my namespace for all custom Dojo classes and I’ve chosen to mimic the path dojox uses to themes.

Quick Peek at a Simple Theme

The levels of complexity within Dojo themes can vary greatly depending on your desire to use simply define colors or implement advanced features like gradations, markers, scrolling, panning, and chart events. Let’s start by looking at a basic theme called Dollar:

Dollar illustrates how simple creating a theme can be; provide a list of colors and you’ve created a custom theme!

Basic Custom Theme: SitePen

Now that we’ve seen how simple it is to make a basic theme, we can easily create a custom SitePen theme base on the SitePen logo colors:

Your colors array can have any number of colors. Colors are repeated in sequence within the chart, if necessary. Check out a few different charts using the new SitePen theme:

Advanced Chart Theming

With the basic SitePen chart theme, we simply defined a series of colors we’d like used in the chart. With advanced chart theming, you can customize everything from default plotareas, axis, series, and marker colors, fonts, and strokes. The amount of control you can have over your charts by creating your own theme is truly incredible. Using Tom Trenka’s “Tom” theme as a template, let’s further customize and enhance the SitePen theme.

You wont need to define every property created above; if a given property isn’t defined, a default value will be used. On the flip side, you may also override each and any of these settings when creating chart instances. This custom theme acts as a middle-ground between chart defaults and chart instance settings.

Take a look at some of our enhanced theme examples:

Using Gradients

The advanced SitePen theme we created above made use of gradients thanks to the dojox.gfx.gradutils class and dojox.charting.Theme.generateGradient method introduced in Dojo 1.5. Gradation instances can be passed to any property that desires a color (usually the fill property.) The signature of the new generateGradient method is:

The fill pattern holds the gradient settings:

Feel free to experiment with the gradation settings to find just the right gradient for you.

New to Dojo 1.5: Gradients, Themes, and Extended Support!

Dojo 1.5 introduces great new features to the charting library, including:

• New Themes
• Gradients
• Experimental support for the SVGWeb plugin in addition to the existing support for SVG, VML, Canvas, Flash, and Silverlight.

Great Charting Resources

• Dive Into Dojo Charting
• Dojox Charting Reference Guide
• Nightly Tests
• Theme Preview
• Introducing Dojox Data Chart
• A Beginner’s Guide to Dojo Charting, Part 1 of 2
• A Beginner’s Guide to Dojo Charting, Part 2 of 2
• Zooming, Scrolling, and Panning in Dojo Charting

Create Your Theme!

While Dojo’s charting library comes with a variety of stylish themes, don’t feel as though you need to choose an existing theme; take a few minutes to create an eye-catching custom theme to match your branding!

Related posts:

1. A Beginner’s Guide to Dojo Charting, Part 2 of 2
2. Zooming, Scrolling, and Panning in Dojo Charting
3. Dive Into Dojo Charting

Substantial user interface improvements

The new version of Dojo offers substantial user interface improvements in the form of the beautiful Claro theme. Claro delivers a modern and engaging visual style for rich internet applications with Dojo’s Dijit library, with the visual enhancements of transparent gradient background images, drop shadows, and appropriate CSS animations (on Webkit and Mozilla-based browsers). It delivers a ‘fit and finish’ that surpasses previous themes and releases, and significantly improves ease of customizing the theme CSS, so you can easily create your own theme by styling elements such as padding and color, without needing to design new background images. All of this while being fully accessible and internationalizable across a growing collection of user interface widgets! Learn more in our Dive into Dijit article.

The portal layout mechanism found in sites such as the personalized Orange home page is provided with Dojo, making it easy to create user-customizable application interfaces. Dojo’s very powerful native vector graphics, charting, and drawing components have received many improvements, including new themes, gradients, and experimental support for the SVGWeb plugin in addition to the existing support for SVG, VML, Canvas, Flash, and Silverlight. This guarantees that your graphics will work natively when possible, but will work everywhere with the simple dojox.gfx APIs.

Stable, backwards and forwards compatible Core

The core Dojo libraries are remarkably stable, making it very easy to upgrade your application from earlier versions of Dojo while receiving a number of improvements to make development easier. dojo.Stateful was added, and dojo.Deferred is improved through an underlying Promises-based API. The core libraries provide everything you need for simple and advanced web sites and apps.

HTML5 & CSS3

Dojo supports many HTML5 features, and has supported many capabilities before they were supported in any browser such as local storage. The Dojo approach is to wrap native support where possible, fixing any glitches, adding API capabilities or simplifications, and offering compatible solutions for older browsers. Whether it’s improved browser history, placeholder hint text for all TextBox-based widgets, a new dojox.style extension to support the CSS transform and transform-origin properties, local storage, rich-text editing, multi-file uploading, or gfx for Canvas/SVG support, we have you covered now, with much more to come in future releases. Check out the presentation and Gorillas examples for a glimpse at what’s possible!

Dojo Mobile

The mobile app space is evolving far too rapidly for the API stability promised by Dojo’s core libraries, so we have many initiatives underway to solve your mobile app development challenges now, and converge on more stable solutions soon. We strive to address challenges for both mobile web apps, and mobile installed apps that embed a web browser. A number of new Dojo Toolkit and Dojo Foundation initiatives are underway:

• dojox.mobile: lightweight mobile web widgets
• dojox.mobile.app: mobile application development framework
• embedjs: Dojo API, optimized for mobile
• TouchScroll: scrolling layer for WebKit Mobile
• wink: mobile web app toolkit

Browser Support

Dojo supports a wide variety of modern browsers. The complete list of officially supported and tested browsers: Chrome 5, Firefox 3.5 and 3.6; Internet Explorer 6, 7, and 8; Opera 10.6 (Dojo Core only); Safari 4.1 and 5. Other browser versions may work fine with Dojo even if they are not officially supported by the project.

Performance and Stability

Not only is Dojo consistently rated among the best performing Ajax toolkits, we also provide solid tools for scaling and growing your application. It’s easy to run into performance problems with any development tool, but the community and various vendors offer solutions to diagnose and solve all of your performance obstacles.

Integrations

It’s always easier to get started when you start with something you already know. Whether you use Zend Framework, Spring, Persevere, Node, Narwhal, cometD-Jetty, DWR, Compuware Uniface, Ruby on Rails, Django, WebSphere, Apache, IIS, or any other HTTP-compliant server-side environment, there’s a simple drop in integration solution to get you up and running quickly. Dojo also offers easy integration with AIR 1.5 and 2.0, Appcelerator Titanium, PhoneGap, and integration hooks with various IDEs and developer tools including Aptana Studio, Komodo, Eclipse, and more.

Demos

We’re in the process of collating the 150 best Dojo 1.5.0 demos. Some of the initial demos were linked to from within this post, and other community plug-in efforts like the MFU project offers an alternative to the dojox.form.FileUploader widget, or the Dojo port of mustache.js as an alternative to dojox.dtl.

Documentation, Support and Assistance

The Dojo web site has a plethora of documentation, and the thriving community offers assistance for everything that’s not already covered. For professional support and assistance, companies like SitePen are available to help you get the most out of Dojo and the open web!

Download Dojo 1.5 today and let us know what you think, and tell us about the great apps you’re building with Dojo!

A Dojo Foundation project

The Dojo Toolkit is part of the Dojo Foundation, the open home for the open web. Beyond the Dojo Toolkit, the foundation has welcomed 3 new projects recently: Zazl, AnimeJ, and wink. cometD-Jetty recently announced a 2.0 release, and Persevere 2.0 beta is due this summer.

Related posts:

1. Platform Optimization Strategies for Ajax Toolkits
2. SitePen Announces Updates to the Dojo Toolkit to Enable Adobe AIR Compatibility
3. End of the Year Dojo News and Updates

However, building a real-life real-time application involves more than just a platform that gives you asynchronous communication, there are a number of other important techniques to understand. We will look at these techniques and introduce project Tunguska that provides some helpful tools to assist in building applications. While a number of Comet projects out there attempt to provide a black box solution to Comet, Tunguska recognizes that most real-time applications involve deep integration into the application and its security, messaging, and data structures. Consequently Tunguska is a set of tools for building real-time applications rather than a closed black box that can’t easily be integrated with. Let’s look at some of these tools.

Connections/Message Queues

The most fundamental concept of building real-time applications is providing the ability to asynchronously deliver messages that occur at any time, to the browser. With new technologies like WebSockets, this is relatively straightforward. You can create a connection to the server and then the server is free to send messages to the browser at any time. However, WebSocket capable browsers are still nowhere near widely distributed enough to rely on (and the WebSocket protocol is still in development, a recent revision rendered the first version incompatible, and more changes are likely to occur due to the immature design).

The most widely used technique for Comet is known as long-polling. With long-polling an HTTP request is made to the server which waits until it has a message to send. The message is sent to the browser as the response, and upon receiving the response the client makes another request to the server. However, the complication of this strategy is that the server does not have a continuous, uninterrupted stream to send messages to the client. There is a time gap between each message/response being sent from the server and the next long-polling request from the browser reaching the server.

However, we obviously don’t want to miss the messages that were generated during these time gaps. Therefore we need to provide a virtual connection by creating a queue where messages can be stored during these time gaps between the response and request. These message queues allow us to effectively emulate a continuous connection, whereby messages can be delivered at any time to the virtual connection. If an active long-polling response is waiting the server can immediately deliver the message, otherwise the message can go into a queue to wait for the next request from the browser to send a message.

Tunguska provides this type of virtual connection or message queueing with its queue module, and message queues can be accessed with the getQueue(clientId) function. Queues are identified by a client id. This function will return a queue object for a given client id passed as the argument. The queue object extends JavaScript’s Array (providing array functions for accessing queued events), provides a send() for delivering events, a message event, and a close event (accessible via addListener() or observe()) as the key functionality.

The queue module does more than just provide a queue object, it also handles timeouts of non-active connections so as to avoid unbounded memory usage, or memory leakage due to accumulation of unused connection objects. It also handles distributed message queues (across multiple processes/machines) as we will see later.

Tunguska also provides a “jsgi/comet” module for the higher HTTP level interaction. A message queue, which acts as a virtual connection to a client, can be obtained from a request object (JSGI or Node) passed into its getClientConnection(request) function. This function will look for the “Client-Id” header to use as the client id for connection identification. If a connection exists with the given client id, it will be returned, otherwise a new connection object/message queue will be created and returned.

The connection object is based on the WebSocket API. Sending a message to the client is as simple as calling the send(message) function. The connection object is also an array. New messages are pushed onto the array and any listeners are notified.

Long-polling handler

A long-polling request handler can now listen for messages by initially checking for any messages in the queue for instant delivery and if no messages are ready to deliver to the client, it can listen for message events to trigger delivery. A JSGI middleware appliance is provided with the jsgi/comet module to do just that. We can easily insert this appliance into a middleware stack:

The optional nextApp parameter can be used to define another middleware appliance that can handle any needed subscriptions and/or other wiring to event triggers to relay messages to the virtual connection object. For example:

Message Routing

One of the key aspects of real-time applications is message routing. When an action or event occurs, the message needs to be routed to the appropriate party. In a chat application, when someone sends a chat message, we need to route and send the message to the recipient. A frequently used mechanism for this is a publish/subscribe hub. A hub consists of “channels” or “topics”, and messages can be published to channels on the hub, and subscribers can listen for messages on these channels. This paradigm decouples sending messages and listening for messages. Message publishers do not need to be concerned with who is subscribed and subscribers do not need to be concerned with the details of who and how messages are published.

Pub/Sub Hub

There are certainly alternate approaches to topic-based pub/sub hubs for message routing. Rather than subscribing to a particular named topic, subscribers could provide message filter functions that filter through all messages for appropriate messages of interests. However, this approach does not scale well. As more diverse topics and messages are being sent through a system, a filter often begins to process more non-matching functions and performance suffers. On the other hand, pub/sub hubs scale well. A normal hash-table based hub maintains constant time message routing regardless of the number of topics. This highly scalable approach fits well with the Node philosophy of making it easy to do the right thing (in terms of scalability) and hard to do the wrong thing. By using the named topics, it is very easy to create highly scalable message routing systems.

Creating a very simple pub/sub hub in JavaScript is actually extremely easy. JavaScript’s hash-based objects make a great core of a hub. You can simply create properties on a “hub” object with names that correspond to topics and values that are arrays of listeners. However, more interesting features than simple topic based message routing are often desirable. Tunguska provides a “hub” module with a rich set of publish/subscribe capabilities.

The Tunguska hub supports globbing or wildcard-based subscriptions for listening for a set of topics (rather than only being able to register for a single topic at once).

It allows for “typed” messages to allow for filtering/routing by type as well as topic (essentially allowing a hub to have a two-dimensional namespace). This hub uses “typed” messages for broadcasting subscription events, sending out a “monitored” event when a topic starts to have subscribers or ceases to have any subscribers.

Tunguska’s hub also supports echo suppression, allowing subscribers and publishers to indicate a client identifier so that published messages do not echo back to the client. These components are important for various applications and are essential for Tunguska’s distributed messaging system, where hubs can be linked together in a cluster.

Clustering

Building Comet applications on a single Node process (single threaded) can be deceptively easy. But, scaling Comet applications to multiple concurrent processes is where the bulk of complexity usually arises. Inter-process communication, non-deterministic request delegation, message framing, and true parallel concurrency can combine to create a formidable challenge compared to the rather simple single-process application development. Fortunately, Tunguska provides clustering support for linking distributed pub/sub hubs together, allowing applications to maintain a simple hub-based message routing system without having to worry about the inter-process interaction complexity.

The core component for building Tunguska clusters is the “connector” module. The “connector” module provides a means of using connections to other processes to coherently link hubs together. These connectors will listen for subscriptions and send subscription requests to other processes, allowing for collection of all messages for a given topic from all processes. A connector can be created by passing it a connection object (that follows the WebSocket API), and the connector will handle the messaging concerns for propagating subscriptions and message routing.

WebSocket connection objects can easily be utilized with actual WebSocket TCP connections to other machines. For inter-process communication on a single machine, multi-node provides easy access to a WebSocket-based connection to the sibling HTTP serving processes. Connecting a set of processes with Tunguska with multi-node is very simple:

Jack/JSGI Support on Other Platforms

In addition to Node, Tunguska can run on any other JSGI-compliant server including Jack 0.3, and should be easily adaptable to RingoJS as well. The main complication with different platforms is creating connectors with alternate forms of cross-process or cross-thread communication. Jack 0.3 utilizes threads for concurrency that implement the WebWorker API and includes special events for connecting to other workers for fully connected workers (achieving fully connected workers, where every worker can talk to every other worker is problematic with the standard worker API since it relies on the less ubiquitous SharedWorker API and requires a high level of name coordination). To use the Tunguska connectors with Jack, you utilize the “jack-connector” module, which provides “worker” events that return connection streams that can be used with the connectors:

Tunguska provides a solid set of tools for building scalable, non-blocking, real-time applications with the flexibility and modularity needed to integrate with essential application logic including custom serialization, authorization/access-control, and middleware routing to truly leverage the asynchronous I/O capabilities of Node. Next up, we will look at how Tunguska, which is a sub-project of Persevere, fits into the greater Persevere ecosystem for data integration with real-time data views, and RESTful content negotiation.

Related posts:

1. Multi-node: Concurrent NodeJS HTTP Server
2. Which Comet Implementation?
3. JSGI vs Connect for Node Middleware

The CommonJS module format is increasingly ubiquitous as the de facto module format for JavaScript. However, if CommonJS modules, by themselves, are directly executed, they require synchronous loading of modules. Synchronous loading is known to be very problematic in the browser since it locks the browser user interface, requires eval-based compilation of scripts which confuses debuggers, and is less efficient than using standard script tags.

The CommonJS group has developed a specification for callback based module loading called the module transport format. The CommonJS module transport format is specifically designed to make it easy to wrap CommonJS modules (which also use synchronous require calls) with a callback wrapper to allow for asynchronous loading on the client. For example, if one had a CommonJS module:

This can be wrapped with the transport format to be loaded asynchronously and used on the client:

There are a couple of excellent client-side libraries available for loading and handling modules in the CommonJS modules format including James Burke’s RequireJS and Yabble. RequireJS also provides a number of functions for easing construction of hand-crafted static modules with wrappers (rather than using server-side generation). These are well documented on the RequireJS API page, so I won’t go into those here, but RequireJS makes it very easy to hand-craft modules for asynchronous loading. Yabble is designed to support direct loading of CommonJS modules (with or without wrapping), and supports other CommonJS APIs including require.ensure for explicit dynamic asynchronous loading of modules.

Automated Module Wrapping

A client-side library like RequireJS can then easily load modules and dependencies (like complex-numbers/math.js) asynchronously and execute the module body when they are available. Of course wrapping modules like this requires writing a lot of extra boilerplate code, especially if you are originally writing your code in CommonJS format, so naturally it is helpful to automate this. Fortunately, there are actually several projects that can automate this wrapping, allowing you to write plain CommonJS modules, and automatically wrap the modules so that they can be asynchronously loaded in the browser. FlyScript is a CommonJS module wrapper written in PHP, and modulr is a Ruby-based module wrapper. Each of these come with their own client-side module loader, but with proper CommonJS transport format compliance they could be used with RequireJS as well.

Another module wrapper is my Transporter project that is actually written as a CommonJS module for JSGI servers (like Jack, and Node with an adapter). Transporter is particularly interesting since it is actually designed to run on a CommonJS server, and therefore paves the way for easily reusing the same modules on the server and client effortlessly. In fact, Transporter will default to loading modules using the same lookup path as the server-side CommonJS environment, to make it easy to share modules. Transporter has been primarily tested with RequireJS and Yabble.

Transporter includes the (configurable) ability to automatically resolve all dependencies on the server. This means that when a module is requested, all the dependencies are automatically included, rather than having to wait for the browser to individually request each dependency, which is much slower due to the latency and overhead of multiple HTTP request-response round trips. Transporter includes a number of other useful options including the ability to explicitly include and exclude dependencies from URLs (within script src), automatic running of the modules (in Yabble, modules aren’t auto-executed), specifying module source paths or loaders, and support for alternate converters (so that different formats besides CommonJS can be used). These are described in more detail in the Transporter documentation.

Dojo, RequireJS, CommonJS

These new asynchronous loading capabilities are not just for CommonJS modules. James Burke has been hard at work in integrating RequireJS with Dojo. He has built a tool for a converting Dojo modules to RequireJS-compatible transport format, integrated RequireJS with the Dojo bootstrap process, and created a full Dojo build that incorporates RequireJS with a fully converted copy of Dojo (including DojoX and Dijit). With this build you can use Dojo in fully asynchronous mode, getting the performance, usability, and debugging benefits of RequireJS’s loader with Dojo. After Dojo 1.5 is complete, we will be looking at various possibilities for using this type of technology and integrating asynchronous loading capabilities in core Dojo and possibly supporting CommonJS modules in Dojo as well. However, this is still a work in progress, and there are couple different options we are exploring, so I will save more details on this for a future post.

Related posts:

1. Pintura JSGI Modules
2. CommonJS/JSGI: The Emerging JavaScript Application Server Platform
3. Introducing Pintura

Multi-node is very easy to use. You simply create an HTTP server object as you would normally do, and rather than immediately calling listen(), you pass it to the multi-node listen function:

As you can see, we can indicate the number of “nodes” or processes to start up, and the port number to listen on. Multi-node will automatically spawn the appropriate processes and pass the socket to each child process to share. The OS kernel then essentially acts as the load balancer, queuing up incoming TCP requests and handing them off to processes as they can accept them. This can actually be more efficient than a separate load balancer, since socket connections are handled as processes request them, making the load balancing immediately dynamic. If a process is loaded with more difficult processor intense requests, it won’t grab as many requests and the other process will pick up the load.

One decision to make is choosing the number of processes (”nodes”) to run. Perhaps the most common suggestion would be to use the same number of processes as the number of CPU cores on the machine. Indeed this is likely to provide the most efficient utilization of the machine’s CPU resources, with minimal context switching overhead. However there can be reasons for using more or less processes. If you don’t want the Node server to consume all of the machine’s resources, you might specify less processes to keep other CPU cores available for other machine tasks.

Alternately, there can be “fairness” advantages to running more processes. Node won’t start processing another request until it finishes its current queue of events. If it has a large queue of expensive event handlers to process, this may increase the latency handling of a request even if it is small, lightweight request. With few processes, this request processing granularity is large. However, with the addition of more processes, the request processing granularity decreases and smaller requests have better odds of being serviced sooner rather than ending up being queued behind other performance expensive operations in the event queue of a few processes. More processes can slightly increase context switching overhead, but this may be worth the improved fairness and latency reduction for quick requests.

One of the core capabilities that multi-node also provides is setting up fully connected inter-process sockets so that processes can easily communicate with other processes. This is very important functionality for situations where data and messages need to be accessible between different processes. Real-time Comet applications like chat demonstrate this need. Chat messages received on one process may need to be sent to other processes so they can deliver messages to their connected client. Even for simple session management such capability can be useful. Since browsers utilize multiple connections to servers, it is very easy for one web application to be connected to different processes on the server, which may need to share session data.

To use the inter-process communication, simply add a “node” listener to the object returned from the listen() call. The “node” event is fired for each new Node process with a “stream” argument that can be used to communicate to that process:

This event should be fired for every other Node process (for this server) that is created, allowing you to communicate to any other process.

Multi-node allows you to easily leverage Node’s new socket sharing capabilities and build truly scalable, concurrent, Node-based web application servers. While multi-node is intended to be usable on its own, multi-node is a sub-project of Persevere and the Persevere example wiki demonstrates how multi-node can easily be used with Persevere applications. Next we will look at how another Persevere sub-project, Tunguska, can leverage multi-node’s inter-process communication for building scalable multi-process real-time applications.

Related posts:

1. Real-time Comet Applications on Node with Tunguska
2. Deterministic Client/Server Interaction
3. CommonJS/JSGI: The Emerging JavaScript Application Server Platform

One of the most powerful pieces of Dojo is also one of the most underutilized: Charting.  The Dojo Charting library lives within the DojoX (extensions) branch of Dojo, and features numerous chart types, options, and a variety of themes. This post introduce you to the charting library and show you how you can take a boring data collection and make it a beautiful visual chart in any modern web browser.

Requiring Charting Classes

A common misconception with many Dojo libraries is that they require a large number of dependencies — this is not the case.  Dependencies change depending on the chart you’d like to make, but a simple chart can be created with only the following Dojo classes:

Two Ways to Play

Much like most of the widgets within the Dijit and DojoX libraries, the charting library allows you to create charts programmatically and declaratively.  Let’s take a look at an example of each approach.

Sample Data

The following JSON is used for our simple Pie chart:

Declarative Chart Creation

The declarative method of creating charts is done with HTML markup.  All chart data such as type, axis, plot, and other chart information is created within the chart container.  Here’s a simple pie chart:

Programmatic Chart Creation

Programmatic chart creation is also quite easy.  The JavaScript code below reproduces the chart above:

Take a moment to compare the two methods and you will quickly notice how similar the structures are. It’s the developer’s choice which method, declarative or programmatic, to use. This tutorial will focus on the programmatic method of chart creation though all examples work with both approaches.

Creating a Simple Chart

Now that the fundamental pieces of the charting puzzle have been explained, let’s create a very basic chart.  This chart will depict website visits over 3 months time.  The chart will be a basic StackedAreas chart with different colors to denote the different months. We’ll take it step by step.

The first step is to place our data in the format with which the chart works. The data for our StackedArea chart must hold each value in one array:

The next step is to create the chart programatically.

Then it’s time to add the plot.

Since the numbers in this type of chart are significant, we want to add an X axis (representing days) and a Y axis (representing traffic / views).

Now that the frame of the chart has been created, it is time to add the information for each month. Since we want to fill areas, we’ll need to pass a stroke and fill color within the series:

Now that our chart is built and the data is in place, we can render the chart:

The result is a beautiful chart:

Chart Animations, Legends, and Extras

As with every other piece of the Dojo library, the Dojo charting library is flexible enough to incorporate other Dojo classes and widgets.  The basic chart we created above is nice but could use a few useful enhancements.

Legend

Adding a legend to the chart is very simple:

Chart Animations

As with basic content on a web page, animation adds some flare and shows focus on an element. Each chart type supports different sets of animations. To keep it simple, we can add a “magnify” animation to the markers on our chart so that the marker grows when the mouse enters it:

Tooltips

Our chart features markers at the designated x/y axis numbers but we can enhance those markers with tooltips so that the user can see the exact number the marker represents.

You may also pair Dijit themes with your chart to style the tooltip; I’ve added the “tundra” theme’s CSS file to enhance the style of my tooltip.

Zooming, Scrolling, and Panning

As you would expect from a vector graphic generation tool, Dojo’s charting library provides a method by which you may flawlessly zoom in and out on any chart. You may also accommodate panning and scrolling on your charts. Read Zooming, Scrolling, and Panning in Dojo Charting to learn more about these features or view a great example of panning, scrolling, and zooming!

Chart Events

Dojo’s charting library also has its own event connection method: connectToPlot.  This method allows you to add event listeners to your chart and trigger functionality based on the given event.

Chart events provide you a wealth of information, including the type of event, coordinates, plot, shape, and more. Visit the Dojo Charting Reference Guide to get detailed information about chart events.

Chart Themes

The Dojo charting library provides over 30 themes to make your charts stand out. You may see a complete list of bundled themes (with preview) in the Dojo Nightly Theme Previewer. SitePen will publish a post in the near future detailing how to create a custom theme!

Chart Families

This tutorial showed you how to create a basic, but beautiful 2D chart; Dojo’s charting library has many advanced charting capabilities though. The different families of Dojo charts includes:

• 2D Charts: The basic two-dimensional chart. (examples)
• 3D Charts: Three-dimensional representations of data. (example)
• Data Charts: Advanced chart, connectable to an external data source. (example | advanced example: Stocker | tutorial)

New Charting Features in Dojo 1.5

The release of Dojo 1.5 introduces new features to the charting library; most notably:

• Linear and radial gradients can now be used with virtually all chart types (and they even work in IE).
• Flexible data sourcing via DataSeries adds the ability to back charts with practically any sort of data store one would like, even supplying secondary information like tooltips.
• Plot and series order manipulations enable one to programmatically shuffle plots and series as needed.
• Indirect events that effectively make it possible for linked plots to share events.
• External events allow a developer to programmatically generate things like mouseovers and apply them to charting objects.
• The default axis is now smarter regarding scaling and sizing.
• A new lightweight invisible axis type allows the user to control plot scale and alignment without displaying an axis.

Great Charting Resources

• Dojox Charting Reference Guide
• Nightly Tests
• Introducing Dojox Data Chart
• A Beginner’s Guide to Dojo Charting, Part 1 of 2
• A Beginner’s Guide to Dojo Charting, Part 2 of 2
• Zooming, Scrolling, and Panning in Dojo Charting

The concept of charting can seem difficult, but Dojo’s charting library is a breeze to dive into!

Related posts:

1. A Beginner’s Guide to Dojo Charting, Part 2 of 2
2. A Beginner’s Guide to Dojo Charting, Part 1 of 2
3. Zooming, Scrolling, and Panning in Dojo Charting

Requiring Proper Classes and Assets

Since Dijit includes a collection of UI components, it comes bundled with four supported themes: nihilo, soria, tundra, and (as of Dojo 1.5) claro. Each theme contains images and CSS files to control the overall display of the widgets. CSS files must be explicitly included into each HTML page:

You can view each theme set using the Dijit Theme Tester. You may also define your own theme.

There is another consideration that must be made when Dojo is included in the page: parseOnLoad. Adding parseOnLoad to the djConfig attribute will direct Dojo to scour the page for elements that should become Dijit widgets and make them such:

This parseOnLoad setting must be true if you prefer automatically instantiating Dijits defined declaratively (which we’ll examine below). You will also need to require Dijit classes you plan to use within the page. For example, If you want the dijit.form.Button widget within your pages, you’ll need to require that class:

In the body tag of your page, or in a parent node of your widgets, you need to define the class name based upon the theme you would like to use.

Now let’s learn the two ways you can create Dijit widgets.

Two Ways to Play

One of the most notable features of the Dijit system is that you may create a Dijit widget in one of two ways: declaratively (using HTML markup and custom attributes) or programmatically (using raw JavaScript, mostly likely within a dojo.ready block). Let’s take a look at how we can make a basic SELECT element an Dojo-enhanced widget.

The Basic SELECT Element

This is a static SELECT element containing a series of OPTION elements. We know we’d like for this SELECT element to become a dijit.form.FilteringSelect widget so we must require this class:

Now that the dijit.form.FilteringSelect class is available, we can use the declarative or programmatic method of enhancing our SELECT element.

Declarative Method

The declarative method of enhancing the SELECT element is done within the HTML element itself:

This declarative example illustrates the use of the dojoType attribute which identifies which Dijit the given element should become. Since we have declared parseOnLoad “true” in our djConfig, Dojo will find this element immediately upon load (due to the element having a dojoType attribute) and instantiate and initialize the widget.

Options of the dijit.form.FilteringSelect class are also custom attributes. This widget will autocomplete when the user types a value and page every 10 items. Just as with a normal SELECT element, “Arshavin” will be selected initially.

Programmatic Method

The programmatic method of enhancing the SELECT element is done completely with JavaScript:

Reminder:  the programmatic method of Dijit creation does not require you to enable parseOnLoad within the djConfig settings.

Since you may have a large form and may not have the desire to target individual elements for Dijitization, you may want to use dojo.behavior to create Dijits by selector:

You could also run a few dojo.query searches for elements and loop through them to create new widgets, but the dojo.behavior method provides a cleaner syntax.

A Dijitized form; easily customizable and themeable.

Accessing Dijit Widgets and Widget Properties

Accessing a specific DOM element can be easily accomplished by using Dojo’s byId method. Dijit features its own byId method which retrieves the Dijit widget registered within the widget system with the ID specified. If the element to be made a Dijit has an ID, the widget ID will be that same value. If the source element doesn’t have an ID attribute, a widget ID will be generated. If we wanted to retrieve the widget object for the declaratively created “players” Dijit above, we would code:

View a listing of all properties and methods of a Dijit using dijit.byId within Firebug.

If we wanted to access the pageSize for which the Dijit widget was created from, we would code:

If we wanted to change the pageSize for the widget, we would code:

Note: Dojo 1.5 introduces “get” and “set” methods to handle property values. In Dojo 1.4 and earlier, you would use “attr” in place of both get and set in the previous example.

Listening to Widget Events

Dijit widgets use Dojo’s native connect method to listen to events on the given widget:

Each widget supports a select number of events so be sure to view the documentation for the widget to ensure the event you’d like to listen to is supported.

The Dijit Collection

Dijit is also an incredible UI library that has the potential to enhance your website and save you an immense amount of time in doing so. Dijit includes a large number of solid widgets including:

• Context, popup, and dropdown menus
• Form element replacements like buttons, combo boxes, checkboxes, radio buttons, and text boxes
• Date and time selection widgets
• WYSIWYG Editors
• Horizontal and Vertical Sliders
• Progress Bars
• Tabs and Accordions
• Tree Structures (including Drag and Drop)
• Dialogs and Tooltips
• Layout widgets with slide controls and splitters

And if Dijit doesn’t have a widget you want, there’s a good chance it’s available in DojoX (Dojo Extensions)! To see many of these widgets in action, visit the Dojo Theme Tester.

Dijit Resources

The following resources will help to aid your Dijit education:

• Dijit API Documentation
• Dijit Reference Guide
• Dojo Nightlies (test files)
• Dijit Theme Tester

Stay tuned for more in-depth Dijit posts in the future. This amazing library contains a vast array of useful widgets to enhance your website!

Related posts:

1. Dive Into Dijit Forms
2. Styling Dijit Form Elements
3. Dijit: Prepackaged

Like all top-notch JavaScript toolkits, Dojo tries to make its classes as flexible as possible, knowing that users of the toolkit may have different ideas about how a given class or class method should work. Luckily, Dojo provides you a number of methods by which you can subclass or modify existing classes. Let’s examine a few ways you can make Dojo classes exactly the way you like.

Creating Dojo Subclasses

The typical method by which you can create a Dojo class (or subclass) is by using the dojo.declare method. The dojo.declare method registers your given class within its designated namespace, while also subclassing any number of classes passed in the method’s second argument.

The following code shows the basic method by which one can create a subclass:

The new class above, davidwalsh.Menu, is a shiny new custom Dojo class that inherits all methods and properties of the dijit.Menu class. My new class also features a new custom property and a new custom method which can do anything I want. Now that we know how to create a subclass, let’s create a realistic example of a useful subclass: davidwalsh.Menu.

davidwalsh.Menu is an enhancement of the original dijit.Menu class; it features two new options and overrides a dijit.Menu method with an end goal of providing a Menu whose PopupMenuItem opens when hovered over instead of clicked.

You may be wondering how to call methods of a superclass from your new subclass. That’s simple too:

As you can see, creating subclasses is a breeze! But what can you do if you simply want to modify an existing Dojo class? Monkey patch it!

Prototype Modification or “Monkey Patching”

Sometimes subclassing existing Dojo classes isn’t the best option or an option at all. You may find yourself in the position where you can only patch an existing Dojo install; in that case, monkey patching is the ideal strategy. Monkey patching is the process by which you modify the prototype of an existing object (in our case a Dojo class). Positives of using a monkey patch approach are:

• All existing objects of this type are instantly changed.
• You don’t need access to the core Dojo files.
• Since you aren’t modifying the core Dojo files themselves, upgrading your Dojo builds will be exponentially easier as you wont have to hunt for your past changes.
• Your patches are more portable as they aren’t placed directly in the core Dojo files themselves.

The following code shows the monkey patching format:

Now let’s take a look at a realistic example. I was recently working with the FilteringSelect Dijit when I noticed that if the first option element within the srcNode (select element) has no value (an empty string value attribute), the element’s label will not display. A very odd bug and definitely not a desired result. What I was able to do was patch the Dijit’s postMixInProperties' method to fix the problem.

That’s just one great example of monkey patching. While monkey patching may not look like the most beautiful technique, it’s an essential part of patching your Dojo installs.

Extending Dojo Classes

The dojo.extend method allows us to add new methods to the class’ prototype, thus providing the new methods to every instance of a given class. If a method name is passed to dojo.extend that already exists for a given class, the new method overrides the original method.

The following code illustrates extending the dijit.Menu class, allowing popup menu items to open during its label’s hover event in addition to the click event.

Note that the original onItemHover method isn’t saved to be executed later — the entire prototype has been rewritten. Essentially we’re rubbishing the original functionality of this method. Now we have a dijit.Menu class that conforms to our needs and doesn’t interfere with our Dojo build itself.

To Subclass, Extend, or Monkey Patch?

There are no hard and fast rules for when to extend a class or monkey patch a class. I do have a few recommendations though:

• Do *not* change one of the core Dojo files; monkey patch or extend.
• Monkey patch the class if you need access to the original prototype.
• Subclass with your own namespace when looking to share code between projects.
• If portability is an important goal, extend the class.

Extend Away!

Extending Dojo classes is the perfect way to fix bugs, enhance native Dojo classes, and prevent you from needing to repeat code. The limitations of Dojo are only those that you put on it!

Related posts:

1. Creating Dojo Widgets with Inline Templates
2. Creating Asynchronous Tests with the Dojo Objective Harness
3. Managing Widget Templates in Dojo 1.4

Performance

To begin with, I did some performance comparisons. The first test is the simplest possible “hello world” application. This was run against a mock server to eliminate any overhead of HTTP parsing and isolate the test to simple request delegation. Here are the results in requests per second:

JSGI-Node: 730K/s
Connect: 204K/s

Here JSGI-Node is shown to be about 257% faster. Next, I created a stack of 9 middleware apps in front of the “hello world” app. These middleware apps do nothing but delegate to the next layer. This was designed to isolate the middleware delegation mechanism. The results are in middleware delegations per second:

JSGI-Node: 80,600K/s
Connect: 2,230K/s

Middleware delegation is over 3000% faster with JSGI than Connect! Why? JSGI is based on a simple, lightweight, pure JavaScript approach to connecting middleware. Middleware apps are simple function closures that accept another app that they can delegate to. Nothing is actually required to wire middleware together. Connect on the other hand has to go through a heavy delegation layer to wire the middleware together. Middleware delegation might not pose a significant bottleneck for simple applications, but as middleware layers accumulate, the speed of delegation becomes increasingly important.

Putting these test together, the full request delegation and middleware delegation through nine middleware layers to a simple “hello world” app results in following requests per second:

JSGI-Node: 675K/s
Connect: 112K/s

With JSGI providing about a 503% better performance with isolated request and middleware delegation.

Here are the test files.

Flexibilty

One of the powerful aspects of JSGI is that middleware is connected by simply passing apps as arguments. This means you can not only create linear stacks, but you can create rich branching tree type request routing structures. Connect on the other hand is really only designed for creating linear middleware stacks. This is useful for demonstrating simple middleware integration, but often real applications require much more sophisticated logic than these simple stacks. While Connect comes with routing middleware, it is not clear if it is possible to create middleware stacks under the different routes (especially with the same ease as JSGI).

Layer Isolation

One of the key concepts of middleware is layering. JSGI provides a simple mechanism for allow each layer to provide a controlled view of the request for the next layer and control the response from that layer. On the other hand, Connect does not provide any mechanism for wrapping and creating new request objects or handling response objects. Altering the view for the next layer means actually altering the request and response objects in place. This fundamentally breaks the layering concept of middleware because when the request object is altered, it is altered across all layers, below and above, not just for the next layer.

Ease of use

Ease of use is in the eye of the beholder, so I will just show so code comparisons. Here is a sample of how you create middleware with JSGI:

And in Connect:

Pintura has a wealth of examples of other middleware applications.

One complaint that has been made about JSGI is that it was not designed for specifically for Node. However, it was designed for asynchronous event-oriented architecture, which is exactly the point of Node, and so there really is no credibility to discounting JSGI for not being Node specific. It is a perfect fit for Node.

Middleware Availability

Simply take a look at the rapidly growing list of middleware modules for Node to see what is available for JSGI. JSGI is based on a collaborative effort of large number of participants in the CommonJS group. Furthermore, JSGI-Node is licensed under the Dojo foundation, which has the known for rock solid CLA-protected IP-encumberance-free liberally licensed software with a track record of being safe to use.

Now to be fair, Connect is about more than just inventing yet another middleware interface. It has some other extremely useful features including a powerful command line startup mechanism and middleware configuration techniques. In fact, Tim Caswell has actually talked about possibly including support for JSGI in Connect. This would be a great addition, and would allow Connect to actually combine the superior JSGI middleware interface with the other cool features in Connect.

The elegant design of JSGI, based on simple idiomatic JavaScript, allows for simple, intuitive middleware, with flexible connections, incredible performance, and connected to a growing ecosystem of reusable appliances.

Related posts:

1. Pintura JSGI Modules
2. CommonJS/JSGI: The Emerging JavaScript Application Server Platform
3. Real-time Comet Applications on Node with Tunguska