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.
We’re happy to officially announce the release of Intern 2.0. This is our most ambitious version yet, with brand new libraries to improve test reliability and performance, new features to make debugging instrumented or compiled code easier, and more!
- Installation times have been reduced by 25%
- Proxy server performance sending static files has been improved by 55%
- CommonJS modules now receive full code coverage analysis and reporting
- Stack traces on test failures now provide accurate line/column information back to the original source code using source maps
- BrowserStack is now supported out of the box
- TestingBot is now supported out of the box
- Chai as Promised is now supported by the functional testing interface
- Bugs and issues related to the WD.js library, like poor error reporting, no longer exist
For more information on this release, including a full list of enhancements, bug fixes, and upgrade advice, visit the release notes. While this is a new major release with a few backwards-incompatible changes, we’ve taken extra care to make sure that only a very small number of tweaks are necessary for an initial upgrade from Intern 1 (usually just updating the tunnel configuration), so in less than 15 minutes you should be up and running with everything that Intern 2 has to offer.
If you or your team would like assistance upgrading your test suite to use all the features of Intern 2, or if you are looking to have a new feature added to Intern, SitePen is here to help with expert advice, support, and custom development services. Get in touch today to learn how we can help.