Dojo has long distinguished itself with a robust and complete application architecture. And the foundation of this architecture has been the store interface, providing clean separation and consistent interface between presentation and data sources. We are committed to continuing to improve this architecture, and in this pursuit, we now releasing dstore, a next generation object store interface and set of data modeling components.
dstore is an exciting new package that provides a number of significant improvements over the prior data store framework, including a more fluent querying API, improved event notification, advanced cross-store filtering, and a more modular mixin system that allows us to easily combine components with alternate format support, advanced querying support, and more. In this post, we want take a brief look at these new features and improvements. From there, you can explore the tutorials and documentation that we have written for this new package.
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
Today we’re happy to announce the release of Intern 2.1. This release contains several bugfixes and improvements to existing functionality, as well as new features to make running tests and handling test results easier. The full list of enhancements and bugfixes is available in the release notes. Here are some of the highlights!
More output options
Two new reporters have been added to Intern: an HTML reporter for the browser client and a JUnit XML reporter.
The HTML reporter is a new default reporter for Intern’s browser client runner (
client.html). It displays at the end of a test run, summarizing the test results and presenting them in an easy-to-read format:
The output of the JUnit reporter, on the other hand, is meant for machine consumption. It aggregates test results and outputs them in a
report.xml file that follows generally accepted standards for JUnit-compatible XML. This makes it much easier to plug Intern into tools that accept JUnit reports, like Jenkins.
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