Dijit is the fantastic layer of widgets that the toolkit provides as drop-in replacements for the standard HTML web controls. This chapter paves the way for PartÂ II by starting out with a fairly nontechnical discussion of Dijit's motivation, philosophy, and goals as an off-the-shelf resource, which dovetails into a discussion of how designers and ordinary page creators can use dijits in markup with little to no programming. The chapter concludes with a guided tour that provides a thorough overview of everything included in Dijit.
Web development is very much an engineering problem, and it has quite an intriguing history, filled with clever hacking and ingenuity. Although the web browser may be the ultimate platform from a conceptual standpoint, the problem from an engineering perspective is that virtually every interesting use case for delivering a rich user experience requires workarounds and augmentation of some form or another. From a very conservative estimate, the lack of conformance to standards by major industry players has produced a landscape littered with more than a half-dozen viable configurations, and along the increase of powerful mobile devices with web browsing capabilities, that number is only going to continue growing.
You already know that Base and Core insulate you from browser inconsistencies and minimize the time you spend writing workarounds; Dijit leverages all of the goods from Base and Core to provide an extensible framework for building modular, reusable user interface widgets.
Although technically incorrect, many Dojo users think of "Dijit" as synonymous with "Dojo" because its widgets are in high demand. Still, Dijit is its own subproject in the toolkit and its logical segmentation from the rest of the toolkit makes it easier to manage and improve as time goes by. In addition to providing you with a collection of off-the-shelf widgets, Dijit provides the infrastructure for you to build your own widgetsâthe same infrastructure that Dijit uses.
Some specific goals of Dijit include:
Developing a standard set of common widgets for web development in an analogous manner to the way that Swing provides an interface for Java applications or Cocoa provides interface controls for an OS X application
Leveraging existing machinery from Core and Base to keep the implementation of widgets as simple and portable as possible
Conforming to accessibility (a11y) standards in accordance with the ARIA (Accessibility for Rich Internet Applications) specification to support the visually impaired and users who cannot use a mouse
Requiring that all widgets be globalized, which simplifies internationalization initiatives by ensuring that widgets are localized and supporting cultural formats and bidirectional (bidi) content
Maintaining a coherent API so that developers can transfer knowledge across multiple widgets and reuse patterns for solving problems
Supporting a consistent look and feel with stylesheets, yet making widgets easily customizable
Making it simple to augment an existing page with a widget or to scale multiple widgets into a full-blown application
Providing full support for bidirectional text (realized as of version 1.1)
Supporting the most common browsers across multiple platforms, including Internet Explorer 6+, Firefox 2+, and Safari 3+
In programming lingo, the problem of developing modular user interface components is well explained by the terms cohesion and coupling. Cohesion is a measure of how well the source code and resources work together to deliver a piece of functionality, while coupling is a measure of a module's dependency on other modules. When designing things like widgets, your goal is almost always to maximize cohesion and minimize coupling.
Dijit answers the call admirably, and even better, it is a
layer of infrastructure that you don't have to write, debug, and
maintain. Building off of Base's
dojo.declare function for simulating
classes, as shown in FigureÂ 11-1, Dijit throws in
standard lifecycle methods for creation and destruction, a
standardized means of responding to events such as key strokes and
mouse movements, and the ability to wrap up the visible
presentation. It also makes it possible to manage it all via markup
As a designer, snapping a dijit into a page via markup is as
simple as including a special
dojoType tag that the parser recognizes
and instantiates into an event-driven DHTML entity. For example, the
following snippet, adapted from ChapterÂ 1,
illustrates how simple it is to include a customized text box for
approximately validating an email address as
part of a formâall in markup:
invalidMessage="Please enter a valid e-mail address"/>
actually use the widget. Sure, many developers
may need to develop or extend widgets, which entails writing
part of your off-the-shelf arsenal. When the page loads, the parser
dojoType tag, requests
any additional resources that are needed (if any) from back on the
server, and transplants a DHTML widget into the page. Laying out a
user interface should be that easy!
Each dijit has a DOM node reference that is its visible representation, and inserting the DOM node reference into the page is all that is necessary to present it to the user. Once visible, its event handlers are exposed, and it behaves as though they were there all along. Here's how you would programmatically construct the same dijit for validating an email address; the parallel between the two approaches is apparent:
 Dijit does not officially support exactly the same array of browsers as Base and Core. The pragmatism behind the decision is that there just isn't a wide enough user base to justify the additional coding, testing, and maintenance for additional browsers like Opera or Konqueror. However, just because "official" support does not exist doesn't mean that it's necessarily difficult to get Dijits working on these platformsâespecially when you consider that Konqueror, Firefox, and WebKit (the core of Safari) are all open source projects.