Blog

Apr 11

Extension Events

By on April 11, 2014 9:41 am

When working in an event-driven environment such as the web, it is important to utilize tools that allow you to create succinct, easy-to-read code that’s extensible and flexible. One great mechanism that Dojo provides is the ability to use extension events.

What Are They?

Extension events are functions that are passed in lieu of an event type to dojo/on. The extension event function should accept a DOM node and an event listener. The function should encapsulate any logic related to the node and invoke the listener when appropriate. The most common case is adding a listener to a native DOM event (click, mouseover, etc.) with custom logic included that determines whether the handler is called or not.

Mar 26

Dojo FAQ: What is the difference between dojo/on and dojo/aspect?

By on March 26, 2014 10:01 am

DojoFAQ

dojo/on and dojo/aspect are two APIs that appear to do similar jobs but actually serve two different purposes. dojo/on is used to setup event listeners for DOM nodes and event-emitting objects. dojo/aspect provides Aspect Oriented Programming facilities so functionality can be run before, after, or around a method call and can even manipulate the input to the original method or the original method’s output.

Mar 5

Dojo FAQ: Why doesn’t Dijit recognize my dgrid instances?

By on March 5, 2014 8:56 am

DojoFAQ

SitePen’s next-generation grid component, dgrid, is designed to be modular and lightweight, allowing you to only load what you need. It has been designed to work well in Dijit-based UIs, but functionality specific to interacting with Dijit is provided in a module that is not loaded by default. Without this module, two common problems often occur:

  • The dijit/registry module will not find dgrid based on its ID
  • The grid will not size correctly when placed inside a layout container widget, such as dijit/layout/BorderContainer
Feb 25

Dojo FAQ: How can I conditionally load AMD modules?

By on February 25, 2014 7:31 pm

DojoFAQ

AMD: Beyond the Basics

If you’ve been using Dojo 1.7+, you know the basic method of loading modules with AMD:

require([
	'dojo/dom',
	'dojo/query'
], function (dom, query) {
	// dojo/dom and dojo/query modules are 
	// loaded and available for use
});

There are times when you may not know the specific modules you want to load during development. There are a few approaches that can be used to determine which modules to load dynamically at run-time.

Feb 18

Dojo Automated Testing Improvements: Updating to Intern

By on February 18, 2014 6:49 am

2013 saw the development, release, and adoption of Intern, SitePen’s modern, standards-based JavaScript testing framework. One of our priorities for 2014 is converting Dojo’s automated tests from DOH to Intern. Although DOH was an advanced testing framework when it was released, the world of web development has seen some important improvements that necessitated the development of a new testing framework:

  • Remote automated multi-platform browser testing from services like Sauce Labs
  • WebDriver, a standard API for controlling web browser behavior, with a cross-browser implementation by Selenium
  • Continuous integration testing for JavaScript with Travis CI
  • Widespread adoption of server-side JavaScript with NodeJS
Feb 13

Creating Dojo Widgets with Inline Templates

By on February 13, 2014 11:58 am

Many Dojo widgets make use of client-side templating for generating the UI. Template HTML files are brought in to the page with dojo/text, parsed and converted to DOM nodes, and placed on the page, allowing our code to make substitutions, instantiate widgets within the template, and hook up events and attach points. However, we may find ourselves dealing with markup generated on the server and delivered on the page that we want to enhance with Dojo. Luckily, it is quite simple to make a custom widget that uses its source node as the template, allowing us to use markup already on the page as the template for our widget.

Feb 12

Dojo FAQ: How do I set up continuous integration testing with my Dojo app?

By on February 12, 2014 9:18 am

DojoFAQ

Continuous integration, the practice of frequently integrating the output of multiple developers into a common repository, has become very popular in recent years. A major benefit of CI is automated testing, which also makes CI useful for single developer projects. Intern, the complete JavaScript test stack from SitePen Labs, makes CI easy with your JavaScript-based source code.

Intern has out-of-the-box support for running both unit and functional tests through Travis CI, a popular hosted CI service that is free for open source projects and offers paid subscriptions for private projects. Before you start with CI you’ll need to write tests for your application. The Intern Tutorial is a good place to start, and the Intern Examples project shows how to use Intern with several popular JavaScript frameworks and libraries such as Dojo, AngularJS, jQuery, and Backbone.

Once you have created your tests, you’ll need to create a .travis.yml file in your repository. This file contains configuration information that tells Travis CI how to construct your testing environment and run your tests. For example, to run tests using Sauce Labs, a hosted web app testing service, your .travis.yml file should look like the following:

language: node_js
node_js:
  - "0.10"
env:
  global:
    - SAUCE_USERNAME: username
    - SAUCE_ACCESS_KEY: access-key
install:
  - npm install
  - cd node_modules/intern
  - npm install --production
  - cd ../..
script: node node_modules/intern/runner.js config=tests/intern

You will need to link your GitHub project to your Travis CI account for Travis CI to detect commits to your repository. The process for doing this is described in the Intern wiki. Once linked to your project, Travis CI will be notified of commits and will automatically run the tests specified in the .travis.yml file in the source code branch that was committed.

Intern is easy to use with Travis CI, but can also be extended to work with other CI tools like Jenkins and TeamCity. In many cases this just means writing compatible reporters to allow Intern to produce output, like unit test and coverage reports, that the CI system can understand. Reporters can be very simple, and the Intern wiki has more information on writing and using them. Intern 1.4 includes an official TeamCity reporter, as well as cobertura and lcovhtml reporters, which are helpful for Jenkins users.

If a simple reporter won’t get the job done, or you just need some help creating one, SitePen offers commercial JavaScript support and development services to assist you in your CI efforts.

Jan 29

Dojo FAQ: Why is dojo.* unavailable when I set async: true in data-dojo-config?

By on January 29, 2014 10:35 am

DojoFAQ
The evolution of the Dojo Toolkit from namespaces to AMD packages has resulted in many changes over the years. In Dojo 1.x, we strive to maintain forwards-compatibility, while introducing new features and best practices in parallel. Mixing modern best practices and legacy code can lead to unexpected behavior.

One issue we see fairly often is setting async: true in the data-dojo-config property of Dojo’s script tag. This configuration setting tells Dojo to load resources as AMD modules using its asynchronous module loader. Many users choose this, but then rely on legacy package names such as dojo and dijit when migrating their old code. Unfortunately, this leads to failures when you try to use dojo.* statements within your application. This is a simple issue to identify and correct.