Like object-oriented concepts from any other programming paradigm, Dojo widgetsâdijitsâfollow particular patterns for lifecycle events such as creation and destruction, are composed according to a particular an anatomical style, and are described by a somewhat specialized vocabulary. This chapter provides a summary of these topics with an extended discussion on the fundamentals of custom dijit design.
Although you already know that dijit is short for "Dojo widget,"
it's helpful to elaborate just a bit before we proceed any further. To
be precise, a dijit is any Dojo class that inherits from a
foundational class from Dijit called _Widget. This class is part of the toolkit's
foundational dijit module, so the
fully qualified name of the class is dijit._Widget. There are several other
foundational classes from Dijit that you'll learn about, but _Widget is the one that provides the primary
ancestor for any dijit.
As you learned in Chapter 10, dojo.declare saves you from writing a lot of
mundane boilerplate; dijits follow suit by tucking away a lot of
complexity in classes like _Widget.
As you're about to see, there are a number of method stubs that you
can override to achieve custom behavior, as opposed to engineering
your own boilerplate.
Tip
You may be wondering why the _Widget class is prefixed with a leading
underscore. When used in relation to dijits, the leading underscore
almost always means that it should not be instantiated on its own.
Rather, it is usually used as a superclass for an inheritance
relationship.
Let's start out our discussion on dijits with the familiar
constructs that define a dijit on a physical levelâthe HTML, CSS,
JavaScript, and other static resources that you've been developing
with all along. Then, with both feet firmly planted, we'll dig deeper
into the dijit lifecycle model by building upon your knowledge of
dojo.declare and work through a
number of increasingly complex code examples that involve the design
of a custom dijit.
As anyone who's ever touched a computer knows, HTML is the de facto standard for displaying information in a web browser. You can standardize headings, paragraph division, form fields, and generally provide just about any kind of markup that's useful for displaying textual information and images. Still, HTML alone isn't very pleasing to the eye: there's no nice formatting involved, and the content is static. The overall structure of a page is quite simple, and it doesn't change in response to user interaction. Given what we've come to expect over the years, the web would be intolerably boring with HTML alone.
Bring in a dash of CSS, however, and the scene changes significantly. Suddenly, the aesthetic nature of the page improves. Whereas HTML alone provides content with very little visual appeal, CSS adds value by improving a page's layout and typesetting. But style alone still results in a static page that leaves the inherent dynamism of human interaction longing for something with a little more life. You could create some nicely typeset pages with HTML and CSS, but that's about it.
JavaScript provided the dynamism that styled HTML so sorely lacked and gave rise to DHTML, which fueled the increasingly interactive online experience that blossomed into this modern era of rich Internet applications. JavaScript brings a web page to life and enables that sheer contentment we enjoy when a simple mouse click, selection in a combo box, or casual keystroke makes you wonder if the computer is reading your mind.
Although we've all come to know a well-designed, interactive web page when we see one, the experience itself can still be quite difficult to achieve; the JavaScript that controls the HTML and CSS can often be quite complex, and even the cleverest of implementations may not be maintainable or especially noteworthy. The central issue at stake is that the HTML, CSS, and JavaScript can be difficult to integrate into a single, cohesive framework. With little cohesion amongst them in ad-hoc designs, synergy is difficult to achieve, and massive amounts of energy is lost in implementing the not-so-interesting boilerplate. Unfortunately, this laborious process can quickly drain motivation and creativity from the parts of the application that really matter.
Fortunately, dijits make matters much easier by providing the foundation upon which you can build a more complex design. They unite the HTML, CSS, and JavaScript into a unified medium, and although not perfect, dijits allow you to think in an object-oriented context much more quickly than you would without them: the end result is that you can quickly get to the heart of your own application before so much of the energy and creativity dries up. Whereas you previously had to provide your own means of uniting the HTML, CSS, and JavaScript, Dojo now does that tiresome work for you, and leaves you to get to the good stuff more quickly.
Just like standalone classes, dijits are self-contained inside of a single directory that corresponds to a namespace. In addition to a single JavaScript file, however, the directory also contains dependencies such as image file and stylesheets. The inherent familiarity of a directory structure provides an innate portability that makes it trivial to share, deploy, and upgrade dijits. Maintenance is also eased because there are no binary formats to unravel, and each component of a dijit can be checked into a version control system like Subversion as a separate file.
While all of the resources that compose a dijit could just be thrown into a single directory in the one-big-pair-of-clown-pants approach, Figure 12-1 displays a common convention for laying out a dijit on disk. Basically, the convention is to just compartmentalize the various facets into subdirectories to make things more manageable.
Dijits unite the HTML, CSS, and JavaScript that are so very central to any web development effort and provide you with a single, unified means of structuring the creativity required of your own application. In the end, you'll save time, effort, and likely obtain a more efficient design. Note that the layout for a minimal dijit that doesn't include a template or CSS is simply a directory with a JavaScript file.
The layout shown in Figure 12-1 shows the template contained in its own separate HTML file, and this setup is typical during the development cycle because it allows members of the development team to work on the template, CSS, and JavaScript files separately.
Fetching the template requires the JavaScript engine to issue a synchronous call back to the server; however, Dojo provides a wonderful way to optimize that synchronous call out the picture entirely: you can include the template as an inline string that's inside of the JavaScript file. Plenty of examples are coming up that illustrate how simple it is to make this happen.
Get Dojo: The Definitive Guide now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
