Perhaps the most important advantage that Dijit brings to your web development efforts is the ability encapsulate user interface components into standalone widgets. If you've done web development for any amount of time, you've no doubt run into the problem of trying to wrap up the HTML, CSS, and JavaScript source files for a user interface into a portable package that is capable of instantiating itself and delivering the intended functionality at the right time with minimal intervention.

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, “Juxtaposing a dijit as a collection of physical resources on disk versus a dijit as a JavaScript Function object”, 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 or JavaScript—delivering the very same functionality to two distinct audiences.

Figure 11.1. Juxtaposing a dijit as a collection of physical resources on disk versus a dijit as a JavaScript Function object

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, Toolkit Overview, 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:

<input type="text"
    length=25
    name="email"
    dojoType="dijit.form.ValidationTextBox"
    trim="true"
    lowercase="true"
    regExp="[a-z0-9._%+-]+@[a-z0-9-]+\.[a-z]{2,4}"
    required="true"
    invalidMessage="Please enter a valid e-mail address"/>

That's it. Not a single line of JavaScript is required to actually use the widget. Sure, many developers may need to develop or extend widgets, which entails writing JavaScript, but the beauty is that once it's written, it becomes a part of your off-the-shelf arsenal. When the page loads, the parser finds the 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!

Of course, anything you can do in markup is also possible with JavaScript. You can dynamically create the very same widget just like any ordinary JavaScript object and insert it into the page with a trivial amount of effort.

As a general pattern, dijit constructor functions have the following signature that accepts a collection of configuration properties and a node reference:

dijit.WidgetName(/*Object*/props, /*DOMNode|String*/node)

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:

<script type="text/javascript">
    var w = new dijit.form.ValidationTextBox({
        length : 25,
        name : "email",
        trim : true,
        lowercase : true,
        regExp : "[a-z0-9._%+-]+@[a-z0-9-]+\.[a-z]{2,4}",
        required : true,
        invalidMessage : "Please enter a valid e-mail address"
    }, n); // n is a node reference somewhere in the page
</script>

While this short section cannot even begin to address the myriad details associated with successfully implementing a web application, it should raise your awareness of the issues involved and highlight the ways that Dijit addresses them. Two of the most common accessibility tasks involve supporting users with impaired vision who need screen readers and users who require the ability to completely navigate an application using only the keyboard.

By default, Dijit inherently supports both audiences. Accessibility for users with impaired vision is addressed by detecting if the browser is operating in high-contrast mode and by detecting whether images are disabled for Internet Explorer or Firefox.^[21] If either accessibility-enabling condition is detected, dijits are rendered according to augmented style, images, and templates as necessary.

For example, Figure 11.2, “Top: the automatic rendering of dijit.ProgressBar when accessibility conditions are detected; bottom: the standard dijit.ProgressBar” illustrates the rendering for a dijit.ProgressBar in both standard and high-contrast mode.

Figure 11.2. Top: the automatic rendering of dijit.ProgressBar when accessibility conditions are detected; bottom: the standard dijit.ProgressBar

Although some of the implementation details can be tedious, here's a basic rule of thumb that goes a long way to achieving accessible widgets for the blind: don't use images (CSS background images or standard images placed with the IMG tag) in such a way that the functionality of a page is impaired if they go missing. A corollary that follows is to ensure alt descriptions are provided; it may seem dirt simple, and it's not always pretty, but it can often get the job done.

The stock widgets provide full keyboard support via standardized use of the tabIndex attribute for controlling the movement of the focus across the application. Additional machinery explicitly manages the focus of complex controls so that tool tips can be displayed as needed—which might always be the case if a screen reader is in use.^[22]

Accessibility initiatives for users with impaired vision and keyboard access are increasing, but in the modern era of Rich Internet Applications, additional support is needed. Common examples of additional support include ensuring users remain aware of changes in state from an XHR call that did not explicitly reload a page, and adequately handling Back button functionality for select actions.

The W3C Web Accessibility Initiative for Accessible Rich Internet Applications (WAI-ARIA) is an effort to ensure that AJAX-powered applications that mimic desktop-like functionality have a set of guidelines for delivering functionality to impaired users. Back in the early 1990s, screen readers could pretty much just read good old HTML. Nowadays, however, widgets are hacked out by lots of nested DIV elements and manipulated with AJAX, which has no meaning to a screen reader. Thus,WAI-ARIA provides the semantics needed to effectively convey information to the blind. For example, these semantics may inform the screen reader that a particular collection of nested DIV elements is a tree, a particular node in the tree currently has the focus, and pressing the Tab key switches focus to the "next" element.

Dijit exposes a collection of functions inspired by WAI-ARIA that are specifically tailored to facilitate adding accessibility to widgets. The W3C working draft "Roadmap for Accessible Rich Internet Applications" (http://www.w3.org/TR/aria-roadmap/) is a great starting point to start learning about ARIA and the overall Web Accessibility Initiative. Specific coverage of roles is outlined in "Roles for Accessible Rich Internet Applications" (http://www.w3.org/TR/aria-role/), while states are covered in "States and Properties Module for Accessible Rich Internet Applications" (http://www.w3.org/TR/aria-state/).

Table 11.1, “WAI functions” summarizes the WAI functions.

In terms of WAI-ARIA, role describes the purpose of a control, and examples of role values might be link, checkbox, toolbar, or slider. state describes the status of a control and is not necessarily a binary function. For example, a control with checkbox role may have a "checked" state that is set to mixed for a partial selection. Other examples of state include checked and disabled, which are both binary (true/false) values.

A Dijit theme is a fully consistent collection of CSS rules that span across the entire set of widgets. To say that another way, you might think of Dijit as being skinnable, where a theme is a kind skin that you apply. If you need to pull some widgets off the shelf and put together something quickly, themes are especially good because CSS becomes one less thing that you have to worry about implementing. As of version 1.1, Dojo includes three great-looking, prepackaged themes:

In your toolkit checkout, you can find a theme tester at dijit/themes/themeTester.html that demos the various dijits with a theme of your choice. Actually looking at the themes on your own screen is the best way to feel them out, as a black and white page can't really do them justice.

The structure of the themes directory has the following pattern, although each primary CSS file generally includes @import statements that pull in various other CSS files as part of a maintainable design (the build tools consolidate CSS files, so official builds only deliver the final file, which minimizes HTTP latency in fetching resources):

themes/
    tundra/
        tundra.css
        images/
            lots of static images
    soria/
        soria.css
        images/
            lots of static images
    nihilo/
        nihilo.css
            images/
                lots of static images
    <your custom theme could go here; just follow the pattern...>

Example 11.1, “Using a theme” explicitly emphasizes the parts of the page that are pertinent to the theme.

<html>
    <head>
        <title>Fun With the Themes!</title>

        <!-- pull in the tundra theme -->
        <link rel="stylesheet" type="text/css"
          href="http://o.aolcdn.com/dojo/1.1/dojo/resources/dojo.css" />
        <link rel="stylesheet" type="text/css"
          href="http://o.aolcdn.com/dojo/1.1/dijit/themes/tundra/tundra.css" />

        <script
            type="text/javascript"
            src="http://o.aolcdn.com/dojo/1.1/dojo/dojo.xd.js"
        ></script>

        <script type="text/javascript">
            //require your dijits here
        </script>
    <head>

    <body class="tundra">
        <!-- use your dijits here -->
    </body>
</html>

You'll notice that actually using a theme is as simple as pulling in a stylesheet and applying the appropriate class name to the BODY tag, although you could have applied the class name to a different tag on the page if you had a good reason not to style the entire page with a single theme. Themes are designed to be applied to any arbitrary page element, whether it is the entire page, a specific DIV section, or a particular widget. This listing also shows that the dojo.css file is also retrieved, which is generally assumed to be the case because it contains some baseline style.

Switching out the theme would be as simple as replacing all of the tundra references with either soria or nihilo. That's it. And that's also as easy as it should be to reskin the page.

We won't belabor the topic of themes because it's really just a system of well-engineered CSS rules, and while it absolutely and positively makes all of the difference to the credibility and desirability of Dijit, it just isn't a topic that lends itself well to the current discussion. If you're interested in themes, however, be sure to pick up a good reference on CSS and start reading through the various CSS files. You'll see definitions like .tundra .dojoButton { /* style goes here */ }, which are usually self-descriptive and easy to locate in Dijit template files or in the page if you are inspecting with Firebug.

Important distinctions must be made between a dijit versus a DOM node: a dijit is a JavaScript Function object that is instantiated from a collection of resources that may include HTML markup, CSS, JavaScript, and static resources like images; the dijit's visible manifestation is inserted into the page by assigning its domNode attribute (the outermost node in its template) into the page.

The distinction between a dijit and DOM node can be further highlighted by juxtaposing the dojo.byId function, which returns a DOM node given a string value, and Dijit's own dijit.byId, which returns the dijit that is associated with a particular DOM node. The differences are listed in Table 11.3, “Difference between dojo.byId and dijit.byId”. Using Firebug to execute the two commands on the following Button accentuates the differences:

<button id="foo" dojoType="dijit.form.Button">click me</button>

<button
    id="foo"
    class="dijitStretch
    dijitButtonNode
    dijitButtonContents"
    waistate="labelledby-foo_label"
    wairole="button"
    type="button"
    dojoattachpoint="focusNode,titleNode"
    role="wairole:button"
    labelledby="foo_label"
    tabindex="0"
    valuenow=""
    disabled="false">

The dojo.byId command returns the DOM node that provides the visible manifestation of an instantiated dijit.form.Button, while the dijit.byId returns a JavaScript Function object that can be examined for all of the standard dijit machinery.

The corollary to the distinction between a dijit and a DOM node is the analogous distinction between a Dijit event and a DOM event. While many dijits have an onClick event, this event is quite different from a DOM node's onclick event in spite of the obvious similarity in naming convention. Take a moment to load and run the following page in the Firebug console; the output highlights the crux of the matter:

<html>
    <head>
        <title>Fun with Button Clicking!</title>


        <link rel="stylesheet" type="text/css"
          href="http://o.aolcdn.com/dojo/1.1/dojo/resources/dojo.css" />
        <link rel="stylesheet" type="text/css"
          href="http://o.aolcdn.com/dojo/1.1/dijit/themes/tundra/tundra.css" />

        <script
            djConfig="parseOnLoad:true"
            type="text/javascript"
            src="http://o.aolcdn.com/dojo/1.1/dojo/dojo.xd.js"
        ></script>

        <script type="text/javascript">
            dojo.require("dojo.parser");
            dojo.require("dijit.form.Button");
            dojo.addOnLoad(function(  ) {
                dojo.connect(dojo.byId("foo"), "onclick", function(evt) {
                    console.log("connect fired for DOM Node onclick");
                });

                dojo.connect(dijit.byId("foo"), "onclick", function(evt) {
                    console.log("connect fired for dijit onclick");    //never!
                });

                dojo.connect(dijit.byId("foo"), "onClick", function(evt) {
                    console.log("connect fired for dijit onClick");
                });
            });
        </script>
    </head>
    <body class="tundra">
        <button id="foo" dojoType="dijit.form.Button" onclick="foo">click me
            <script type="dojo/method" event="onClick" args="evt">
                console.log("Button fired onClick");
            </script>
        </button>
    </body>
</html>

To summarize, this page defines a simple method in markup for a simple Button, provides an implementation for its onClick method, and defines three connections: one for the DOM node's onclick event, and connections for the dijit's onclick and onClick events. However, dijits do not have an onclick event, so the example demonstrates that the common mistake of trying to connect to it is a pitfall that can produce bugs that are quite hard to track down and fix.

Aside from seeing some references in the introductory material in Chapter 1, Toolkit Overview and some exposure in the drag-and-drop examples from Chapter 7, Drag-and-Drop, the parser hasn't been formally introduced because its most common use case is instantiating widgets in a page. Without further ado, here's an official example of the parser instantiating a widget from markup. Note the emphasized lines in Example 11.2, “Automatically parsing a widget”, which highlight where the parser-related action is happening.

<html>
    <head>
        <title>Fun With the Parser!</title>

        <!-- pull in the standard CSS that styles the stock dijits -->

        <link rel="stylesheet" type="text/css"
href="http://o.aolcdn.com/dojo/1.1/dojo/resources/dojo.css" />
        <link rel="stylesheet" type="text/css"
          href="http://o.aolcdn.com/dojo/1.1/dijit/themes/tundra/tundra.css" />

        <script
            type="text/javascript"
            src="http://o.aolcdn.com/dojo/1.1/dojo/dojo.xd.js"
            djConfig="parseOnLoad:true"
        ></script>

        <script type="text/javascript">
            dojo.require("dojo.parser");
            dojo.require("dijit.form.Button");
        </script>
    </head>

    <body class="tundra">
      <button dojoType="dijit.form.Button"
 >Sign Up!</button>
    </body>
</html>

To summarize what's happening, there's just a simple page that includes an off-the-shelf button from Dijit that does absolutely nothing except look pretty—but for the purposes of introducing the parser without diving into Dijit specifics, this is just fine. The only thing you need to know about the Button dijit at this time is that it is fetched via a call to dojo.require and inserted into the page via the dojoType tag.

You won't see any direct invocations of the parser in Example 11.2, “Automatically parsing a widget”; that's by design. The vast majority of the time, you simply dojo.require dijits into your page, set the parseOnLoad flag in djConfig, and let the rest happen behind the scenes. In fact, that's all that occurs in this example. It's worth taking a moment to ponder just how absolutely elegant it is that you can take a dijit off the shelf and, in just a few keystrokes, insert it into the page. No additional headache, hassle, or fuss is required.

There are bound to be times when you will need to manually parse a page or some node in the DOM. Fortunately, it's just one function call away. Consider Example 11.3, “Manually parsing a page”, a variation that manually parses the widget in the page.

<html>
    <head>
        <title>Hello Parser</title>

        <!-- pull in the standard CSS that styles the stock dijits -->

        <link rel="stylesheet" type="text/css"
          href="http://o.aolcdn.com/dojo/1.1/dojo/resources/dojo.css" />
        <link rel="stylesheet" type="text/css"
          href="http://o.aolcdn.com/dojo/1.1/dijit/themes/tundra/tundra.css" />

        <script
            type="text/javascript"
            src="http://o.aolcdn.com/dojo/1.1/dojo/dojo.xd.js"
            djConfig="parseOnLoad: false"
        ></script>

        <script type="text/javascript">
            dojo.require("dojo.parser");
            dojo.require("dijit.form.Button");
            dojo.addOnLoad(function(  ) {
              dojo.parser.parse(  ); //manually parse after the page loads
            });
        </script>
    <head/>
    <body class="tundra" >
      <button dojoType="dijit.form.Button" >Sign Up!</button>
    </body>
</html>

Although manually parsing the entire page is useful, you'll more often need to manually parse a DOM node. The parser accepts an optional argument that provides the root of a node in the DOM tree that it scans for dojoType tags and instantiates. Thus, you provide the parent of the node you wish to parse to the parse function. Here's one possible modification of the previous code block that illustrates:

<script type="text/javascript">
  dojo.require("dojo.parser");
  dojo.require("dijit.form.Button");
  dojo.addOnLoad(function(  ) {
    //The parser traverses the DOM tree passed in and instantiates widgets.
    //In this case, the button is the only leaf in the tree, so it is all that
    //gets parsed
    dojo.parser.parse(document.getElementsByTagName("button")[0].parentNode);
  });
</script>

Although what the parser accomplishes really does seem like magic, it really just boils down to rigorous, well-designed automation. As you now know, the parser has two primary use cases: parsing the page on load via djConfig="parseOnLoad:true" or manually parsing a widget. This section elaborates on the details that go into making those two things happen.

Parsing a widget when the page loads entails three basic requirements:

Manually parsing a widget that has already been defined in markup after the page loads is similar:

But what about the actual parsing process? You know—the part about finding all of the dojoType tags and instantiating them into widgets? Again, it's all simple automation when you get right down to it. Here's exactly what happens:

Hopefully, that didn't make you feel the same way that you did when you learned that Santa Claus wasn't real, but you had to learn sometime. The next chapter focuses exclusively on dijit lifecycle methods where dedicated coverage of these concepts is provided.

As you learned from an earlier section on the parser, it's pretty trivial to stick a dijit into the page. You require in the resources, provide the dojoType attribute in a tag, and have the parser go to work. For completeness, Example 11.4, “Creating the NumberSpinner widget in markup” shows how we'd follow that very same pattern to instantiate a NumberSpinner dijit.

<html>
    <head>
        <title>Number Spinner Fun!</title>


        <link rel="stylesheet" type="text/css"
          href="http://o.aolcdn.com/dojo/1.1/dojo/resources/dojo.css" />
        <link rel="stylesheet" type="text/css"
          href="http://o.aolcdn.com/dojo/1.1/dijit/themes/tundra/tundra.css" />

        <script
            type="text/javascript"
            src="http://o.aolcdn.com/dojo/1.1/dojo/dojo.xd.js"
            djConfig="parseOnLoad: true"
        ></script>

        <script type="text/javascript">
            dojo.require("dojo.parser");
            dojo.require("dijit.form.NumberSpinner");
        </script>
    <head>
    <body class="tundra">
        <form> <!-- some really awesome form -->
            <input dojoType="dijit.form.NumberSpinner"
                constraints="{min:0,max:10000}" value=1000>
            </input>
            </form>
    </body>
</html>

While you'll often create dijits in markup, programmatic creation is no less common and the process is the very same as creating any other Function Object because that's exactly what a dijit is—a Function Object. In general, the constructor for a dijit accepts two parameters. The first is an Object that provides properties that should be passed in, and these are the same properties that you would be including in the tag if you were creating in markup. The second parameter is a source node or the id for a source node that identifies the placeholder that the dijit should replace:

var d = new module.DijitName(/*Object*/props, /*DOMNode|String*/node)

Example 11.5, “Programmatically creating the NumberSpinner widget” programmatically creates the NumberSpinner and produces the very same effect as Example 11.4, “Creating the NumberSpinner widget in markup”.

<html>
    <head>
        <title>Number Spinner Fun!</title>

        <link rel="stylesheet" type="text/css"
          href="http://o.aolcdn.com/dojo/1.1/dojo/resources/dojo.css" />
        <link rel="stylesheet" type="text/css"
          href="http://o.aolcdn.com/dojo/1.1/dijit/themes/tundra/tundra.css" />
        <script
            type="text/javascript"
            src="http://o.aolcdn.com/dojo/1.1/dojo/dojo.xd.js"
        ></script>

        <script type="text/javascript">
            dojo.require("dijit.form.NumberSpinner");
            dojo.addOnLoad(function(  ) {
                var ns = new dijit.form.NumberSpinner(
                    //props
                    {
                        constraints : {min:0,max:10000},
                        value : 1000
                    },
                    "foo" //node id
                );
                // do other stuff with ns here...

            });
        </script>
    <head>
    <body class="tundra">
        <form>
            <input id="foo"></input>
        </form>
    </body>
</html>

This particular example displays a nice little text box with a control that allows you to adjust the value from either the arrow keys on the keyboard, by clicking the arrow controls on the dijit itself, or though manual keyboard entry. In any case, the min and max and key/value pairs are part of the constraints attribute that can be customized to form the upper and lower values for the spinner with the arrow keys or when clicking on the controls; the value attribute provides the default value just like in ordinary HTML. Manually changing the value via manual keyboard entry, however, still changes the value, which may trigger a tooltip-style error message. Figure 11.3, “Left: a NumberSpinner dijit changing its value via keyboard or mouse control; right: the default display when manual keyboard entry enters a value that is out of bounds” illustrates what happens.

Figure 11.3. Left: a NumberSpinner dijit changing its value via keyboard or mouse control; right: the default display when manual keyboard entry enters a value that is out of bounds

You've probably already made the connection about the NumberSpinner 's keyboard entry and a11y, but there are some other niceties that are worth trying out right away. You've no doubt noticed the numeric formatting that is automatically applied to separate every three digits of numbers greater than 999. Note that if you were rendering the page for a supported locale that used a different separator for the digits, it would have happened automatically: locales like en-us use commas to separate values, like 1,000, while Spain, the es-es locale, for example, uses dots to separate the digits, like 1.000. Figure 11.4, “Dijits handle special formatting for the supported locales right out of the box with no additional configuration required; the top NumberSpinner was configured with en-us while the bottom NumberSpinner was configured with es-es; the dijit internally took care of the formatting details” demonstrates. Try it for yourself by modifying your default locale in djConfig. For example, to set a default locale of Spain, you could do the following:

djConfig="locale:'es-es'"

Figure 11.4. Dijits handle special formatting for the supported locales right out of the box with no additional configuration required; the top NumberSpinner was configured with en-us while the bottom NumberSpinner was configured with es-es; the dijit internally took care of the formatting details

Another great out-of-the-box feature that Dijit supports is the notion of controls being typematic—that is, they respond in special ways to holding down a mouse button or keyboard key. If you try holding down the mouse button on one of the controls for the NumberSpinner, you should notice that it gradually increases for the first 10 or so numbers and then eventually speeds up and moves rapidly. Not surprisingly, keyboard navigation works the very same way. The Page Up and Page Down buttons also work and adjust the values by multiples of 10 by default.

In addition to being able to programmatically write ordinary JavaScript to control and extend widgets, Dojo also provides the ability to define the JavaScript directly in markup by including a special type="dojo/method" attribute in SCRIPT tags. This can be very convenient for designers as well as anyone who needs to rapidly prototype a new idea. What's especially notable about defining methods in markup is that the keyword this refers to the containing widget, so you have instant access to the context you'd expect.

Consider the following update to the example code listing that defines methods in markup:

<!-- snip -->

    <script type="text/javascript">
            dojo.require("dojo.parser");
            dojo.require("dijit.form.NumberSpinner");
            dojo.require("dijit.form.Button");
     </script>
    </head>
    <body class="tundra">
        <form>
            <div dojoType="dijit.form.NumberSpinner" jsId="mySpinner
"

                constraints="{min:0,max:10000}" value=1000>
                <script type="dojo/method">
                    dojo.mixin(this, {
                        reset : function(  ) { this.setValue(1000); }
                    });
                </script>
            </div>
        </form>
        <button dojoType="dijit.form.Button" onClick="mySpinner.reset(  )">
reset</button>
    </body>
</html>

To sum up the effect of the changes, the jsId attribute gave the NumberSpinner a global variable name mySpinner, which was referenced in a Button's onClick method. The actual body of the reset method was established by the special script tag included inside of the dijit. The script tag providing anonymous dojo/method is executed after its constructor runs, so that any values passed in via attributes included in markup would be available.

Also, note that whereas the previous listing used an input element to create the spinner, the new listing uses a div tag. The reason why an input tag will not work with the updated listing is that it does not allow innerHTML. The tag had to be switched to a type that does allow innerHTML in order for it to work. If you're wondering why a div tag wasn't used all along, it really comes back to one primary issue: the ability to have a semantically correct page that works without any JavaScript involved. In other words, the previous form using an input element is a semantically correct input control even if JavaScript were disabled (for whatever reason), whereas the div -based spinner is not. Most of the time, this isn't an problem, but when designing a degradable page, it is very important to know your basic HTML and be aware of these issues.

While the additional reset button may make a great addition for a mouse-based control, note that pressing the Escape key on the keyboard would have reset the spinner to its original value without any additional work at all.

As an improvement that produces the very same effect but with less code, consider the following change to the dojo/method script tag:

<script type="dojo/method" event="reset">
    this.setValue(1000);
</script>

Instead of being executed automatically a single time after the constructor, which is the case for anonymous dojo/method script tags, this approach performs the work of actually creating the reset method and attaching it to the widget on your behalf. If there had been arguments involved, an additional args attribute could have been specified. For example, args="foo,bar,baz" would have allowed for passing in three named arguments to a method defined in markup.

The very naming convention for a category of "form dijits" implies that the dijits are designed to be used inside of a form. While this is certainly true, form dijits may also be used outside of forms or in a special dijit.form.Form dijit that provides some extra methods and extension points. Here's a very brief overview of what is included in each of those chapters. Recall that all dijits are a11y compatible and easily internationalized, where applicable.

Traditional techniques for complex layouts used to involve extensive CSS work. While CSS may not be rocket science, writing, maintaining, and testing it on multiple browsers requires nontrivial effort—especially if you're not a CSS guru. Layout dijits allow the layout to be constructed in markup—without resorting to nested tables—which seems to have made laying out a page a lot simpler. Layout dijits, in general, may be arbitrarily nested, which allows for extremely sophisticated designs at a fraction of the time involved with more traditional CSS-based techniques. Here's a synopsis of what Dijit provides:

Application dijits are the "other" category; they are all very common elements for any application that even begins to approach RIA functionality. Menus, toolbars, dialog overlays, and rich text editors are all part of the mix, and these dijits are so easy to use that you can't avoid wanting to: