The way modules are loaded changed with the introduction of modern Dojo (1.7+). Dojo now uses the AMD format for packaging and loading modules within an application. AMD avoids the use of globals, which limits the likelihood of unintended interactions between modules. By leveraging AMD and the flexible configuration provided by the Dojo loader, we can load different versions of the same package on a page without dangerous interactions.
Making a case
When building a select control in a form there are times where its available options need to change dynamically in response to a change in another control. For instance, a form with both country and state/province select controls might require the options in the state select to change based on the country select’s current selection. This is what we would call a dependent, or linked, select. One way to accomplish this is by watching changes in the selection state of one select and finding and setting the appropriate selection values on the other.
The selection values of Dijit Select widgets can be provided as an array of
options objects or a dojo/store instance. We will walk through an example creating a dependent select for both types of source data.
Bootstrap is a framework created by Twitter’s developers to consolidate their HTML/CSS design and widgets. Bootstrap provides a clean responsive design, but the set of widgets it includes is limited, especially when compared to what’s available in the Dijit library. The CSS/HTML theme can be used independently of the widgets, but how do you use the Bootstrap theme with the Dijit library?
As you may have guessed, it’s not quite as simple as including the relevant Bootstrap CSS files. However, Dijit supports custom themes, so with a bit of work the elements of the Bootstrap theme could be ported to Dijit widgets. Fortunately, this was just what the dbootstrap project set out to accomplish.
For a better idea of what this Dijit/Bootstrap marriage looks like, check out the dbootstrap gallery, a modified version of Dijit’s Theme Tester that also includes dgrid. Let’s take a closer look at dbootstrap and how to use it in your Dojo application.
When developing for the web, it is a recommended best practice to always test your application during development with a web server. This is for two primary reasons. By running a web server, you can approximate a production environment similar to how your application will be served to your users. Also, browsers implement a same-origin policy that is different for quasi-protocols like
file://. Many of Dojo’s modules like
dojo/text, Dijit templates, and
dojox/gfx depend on loading files from the same origin.
A common practice when adding new elements to a document is to add them to a container DIV and then insert that node into into a document. A lesser used alternative is the
DocumentFragment class. So, what is a document fragment, and when should you use one instead of a container DIV?
- Using when(value) to always create a promise
- Passing callbacks to be applied directly to the value
When writing tests for an application, it’s prudent to add mock or stub data in order to allow code to be properly tested in isolation from other parts of the system. Within a normal Dojo application, there are typically three places where mocking will occur: I/O requests, stores, and module dependencies.
Dojo’s store API is a common interface for providing data to user interface widgets, such as dgrid, Dijit Select, and Dojo Charting. The beauty of having a consistent API is that once you’ve defined an interface for a data source, that data becomes easily available to all widgets that support the store API. We’re going to look at how you can create a basic, read-only
dojo/store API-compliant module for accessing GitHub’s API (specifically, GitHub issues), an example of implementing your own Dojo store.