Blog

May 15

Dojo FAQ: Is there a way to extend a widget’s template (e.g. Dialog)?

By Mangala SSS Khalsa on May 15, 2013 3:02 pm

There are indeed ways of doing so, but while Dijit strives to provide extensible modules that can serve as a basis for your own custom modules, templates are a tricky thing to deal with.

A brief review of some of the best practices for maintenance & longevity when building applications with Dojo:

  • Use a separate namespace for your custom modules rather than dojo, dijit, or dojox – this makes it very clear which modules come from the Dojo distribution and which modules were created for your application or organization
  • Never edit Dojo modules directly – Dojo provides dojo/_base/declare for inheritance and provides many modules that were designed to be extended or used as mixins

With a clear separation in your codebase between Dojo modules and custom modules created for your application you have a much greater chance of a simple & successful upgrade to a new release of Dojo.

May 8

Dojo FAQ: Does Dijit have a confirm dialog?

By Mangala SSS Khalsa on May 8, 2013 10:01 am

No, Dijit does not provide pre-configured dialogs, like alert, confirm, or prompt.

Why? As simple as these may seem on the surface, each organization or application often needs something subtly different in terms of layout, appearance, behavior, events, and internationalization. Dojo and Dijit provide all the elements you need to make a variety of dialogs, including dijit/Dialog, dijit/form/Button, dojo/on, dojo/Deferred and dojo/i18n.

The time spent creating a dialog that suits your needs perfectly will be small compared to the overall time spent developing an application, and you will have a reusable module tailored to your specific needs that you can use throughout your application, or even across applications throughout your organization. Creating a custom dialog also ensures that teams of developers don’t have to struggle to get a generic confirmation dialog to respond and look like other dialogs in the application.

That being said, Dojo is an open-source, community-driven project, and you are encouraged to share general-purpose components with the community:

May 2

Dojo FAQ: Why doesn’t my BorderContainer display?

By Mangala SSS Khalsa on May 2, 2013 9:52 am

One of the most common questions we get asked is why a BorderContainer may not be displaying. There are two very common gotchas that we typically see when it comes to BorderContainer use.

Width/height issues

The most common culprit when your dijit/layout/BorderContainer doesn’t display at all is forgetting to set the width and height of the html and body elements. Somewhat counter-intuitively, these elements default to a width and height of 0, only expanding to fill content.

A BorderContainer is often configured to expand to fill its container node like so:

#borderContainer {
    width: 100%;
    height: 100%;
}

In a typical scenario, if all you have on a page is a BorderContainer directly under the body element, the body will have height and width of 0, so the BorderContainer will calculate the space it has to work in and will fill 100% of… no space! That is, unless you set width and height explicitly, like so:

html,
body {
    width: 100%;
    height: 100%;
    margin: 0;
    padding: 0;
    overflow: hidden;
}

With the html and body elements configured to use the full viewport, your BorderContainer will be able to expand as you would expect.

Did your widget start?

As with all Dijit widgets, if you are using BorderContainer programmatically, you need to ensure that you explicitly call startup after creating it and putting it into the document:

require([
    'dijit/layout/BorderContainer'
], function(BorderContainer){
    var mainContainer = new BorderContainer({
        id: 'mainContainer',
        design: 'headline'
    });
    mainContainer.placeAt(document.body);
    mainContainer.startup();
});

In Closing

If your BorderContainer fails to display, check two things:

  • The size of the BorderContainer's containing element – if it’s the body element, make sure both the html and body elements are sized appropriately.
  • If using BorderContainer programmatically, ensure that you have called its startup method after creating and placing it.

If it still isn’t showing up, check your console and make sure there are no errors — a parsing error will often cause subsequent content to not display correctly.

May 1

Meet your newest Intern

By Paul Bouchon on May 1, 2013 9:10 am

The Intern

JavaScript tooling has gained a huge amount of attention over the past few years, no doubt due to the language’s rapidly increasing popularity and maturity. Many fantastic utilities and powerful debuggers have emerged to help close painful gaps for Web developers, but despite these advancements, high-quality JavaScript testing is still notably absent.

Up to this point, JavaScript authors have had to pick and choose testing tools with incredibly fragmented feature sets. Whereas one tool might support easily running tests manually in many browsers, another might allow command-line automation but only use PhantomJS. A third might be designed to integrate with a continuous integration service, where a fourth might support none of that but allow you to emulate true browser events from outside the JavaScript sandbox. One might have so many plugins that it’s impossible to figure out which ones to use, whereas another might be so inflexible that adding any new features is impossible. It’s a mess.

Intern, from SitePen Labs, is different. It combines all the best features from various testing tools (plus a few new ones of our own) into a single, versatile, easy-to-use, standards-based browser testing stack for JavaScript. We’ve been using this testing framework internally for a while with great success and are really excited to be able to make this level of JavaScript testing available to the entire Web community.

For more information on Intern’s features, usage examples, and documentation, please visit the Intern Web site. If you just want to get started straight away, take a look at the quick start guide. We’ll be making an npm package available very soon to make getting started even easier. Bug reports and feature requests can be posted to the GitHub issue tracker. If you have any other questions, we’re here to help! Free end-user support is currently available via Stack Overflow. SitePen also offers commercial JavaScript support if you need a little extra TLC.

Please let us know in the comments how Intern can work better for you, so you can focus on delivering high-quality code while the Intern does the testing. Happy coding!

Apr 26

Dojo FAQ: What properties are available to me on the event object when using dojo/on?

By Mangala SSS Khalsa on April 26, 2013 11:20 am

The dojo/on module not only provides a simple, consistent interface for registering event handlers, it also ensures that the event object passed to your handler implements the W3C event model (W3C recommendation, MDN reference).

While most web browsers provide DOM events in a manner compliant with the W3C model, prior to version 9 Internet Explorer implemented its own model with the attachEvent method and some different properties on the event object.

Using dojo/on allows you to interact with event objects using the W3C event model regardless of the web browser. Specifically, the following properties and methods are added to event objects in IE8 and below (see the MDN reference for details – keep in mind some properties only apply to certain event types, like KeyboardEvent and MouseEvent):

  • target
  • currentTarget
  • relatedTarget
  • charCode
  • keyChar
  • charOrCode
  • stopPropagation()
  • stopImmediatePropagation()
  • preventDefault()

Non-standard MouseEvent Properties

The properties pageX, pageY, offsetX, offsetY, layerX, and layerY are not normalized as it is expensive and often not needed, but the dojo/dom-geometry module provides a convenient method for doing so: normalizeEvent.

require([
    'dojo/on',
    'dojo/dom-geometry'
], function(on, domGeom){
    on('button', 'click', function(event){
        domGeom.normalizeEvent(event);
        console.log(event.pageX, event.offsetY, event.layerX);
    });
});

In Closing

Using Dojo provides an easy, consistent API across web browsers, smoothing out incompatibilities and inconsistencies, with a focus on adhering to open standards. Even if you’re not ready to update existing code that depends on certain properties (like layerX, layerY), you can still start using Dojo and take advantage of normalization methods to ensure your existing code works as expected.

Apr 17

Dojo FAQ: dojo/domReady vs dojo/ready

By Matthew Maxwell on April 17, 2013 8:55 am

We answer many, many, many questions on a daily basis through our Dojo training workshops, JavaScript support plans and during our customers’ development projects.

We have bucket-loads of answered questions. What to do with them all…
Oh? Provide you with the answers? Ok.

Here it is! Each week we’ll answer a commonly asked question about Dojo and then we’ll give it to you. Here we go!

Apr 3

Introducing dojo-amd-converter

By Dylan Schiemann on April 3, 2013 9:30 am

AMD offers many benefits over the legacy Dojo module syntax. While Dojo is forwards-compatible, to take advantage of the benefits of AMD, developers are often faced with the challenge of migrating and refactoring large quantities of boilerplate code from the legacy dojo.provide/dojo.require syntax to AMD’s define and require. As we make the upgrade to AMD in our projects, we also usually want to leverage the latest version of our evolving APIs. With early work beginning on Dojo 2.0, we definitely need to work together as a community to automate as much of the upgrade process as possible.

Introducing the dojo-amd-converter

We have created an alpha quality release of dojo-amd-converter, a tool for helping you make a one-time migration of your existing source code to a newer version of Dojo.

Be warned, the tool handles only 70-80% of the manual conversion process, and generally does better with more standard usage of Dojo. Normally we wait a bit longer before announcing our projects, but this should be useful in its early alpha state. We know this tool has quite a few open issues that need to be fixed and we invite you to help us improve it.

Our hope is that this conversion tool, which is today useful for converting pre-AMD code to AMD code, could also form the basis for a community effort to make it possible to migrate code bases more efficiently from Dojo 1.x (pre-AMD or AMD) to Dojo 2.x. That work has not yet started, since Dojo 2.0 is not yet an actual thing.

Jan 25

Dojo Tutorial: Feature Detection and Device Optimized Builds

By Dylan Schiemann on January 25, 2013 3:50 pm

As part of our great updates to the Dojo Tutorials for Dojo 1.8, we’ve been busy creating several new tutorials.

Feature Detection and Device Optimized Builds

preview Dojo 1.7+ now uses the popular has() pattern for feature detection in combination with a has()-aware build system. While it is easy enough to write feature detection tests with ad-hoc JavaScript expressions, the has() pattern defines a specific syntax such that the build system can detect these feature-based branches, and one can create application builds that are highly optimized for specific devices, with known feature shims factored out.

Check out the Feature Detection and Device Optimized Builds tutorial for Dojo 1.8 and 1.7!

Want to see a specific Tutorial? Want to Learn More?

Is there something you’d like to learn how to do with Dojo? Always wanted to know how something in Dojo works? Leave us a message in the blog comments and we’ll see about getting a tutorial created for you. Or sign-up for an upcoming SitePen Dojo Workshop to get a fully immersive hands-on experience with Dojo.

Jan 24

Performance Comparison: dgrid OnDemandGrid and Dojo Grid

By Betsy Gamrat on January 24, 2013 9:22 am

SitePen’s dgrid project leverages the AMD loader and other features new since Dojo 1.7 to minimize the load and rendering times of dynamic grids in web applications. In this post, we conduct tests in four common scenarios for both dgrid and DojoX DataGrid, contrasting startup, render, and destroy times in several popular browsers. We also discuss the amount of code involved in loading common components of dgrid and DojoX DataGrid.

The demos below test each grid in three phases:

  1. Startup – the time required to create the instance of the grid, define the columns and any other configuration, and display the grid with headers but no data
  2. Render – the time required to process and present the first page of data in the grid (25 items); since both grids use lazy loading, render time for the first page is representative for all pages
  3. Destroy – the time taken to remove the grid’s DOM from the document, and perform any internal cleanup
Jan 18

Generating and Viewing Custom Dojo API Documentation

By Paul Bouchon on January 18, 2013 12:30 am

When developing a JavaScript framework that others will consume, it’s hugely beneficial to provide clean, organized API documentation to accompany your codebase. With the August release of Dojo 1.8, we saw a brand new, extensible documentation parser, which is used to generate output for Dojo’s API viewer. Generating documentation for any project and serving up a custom API viewer is easy, and this post will show you exactly how to do it.