What a great year 2013 has been!
We’re feeling (collectively) like Ebenezer Scrooge in the final chapters of Charles Dickens’ A Christmas Carol – except we haven’t been jerks up ’til now and we think working at SitePen is a year-round Christmas vacation, unlike the earlier chapters wherein Scrooge forces poor Mr. Cratchit to work by the heat of a candle. That’s just mean. Anyways, the point is, we’re feeling fairly festive and because of this, we have something special for you!
Sign up today and get Dojo 101 for FREE
We would like to give you a FREE pass to our Dojo 101: Fundamentals workshop (a $649 value!) when you sign up for Dojo 201: Interfaces or Dojo 202: Architecture. All you have to do is register before December 31, 2013 for any 2014 workshop and enter promo code FREE101!
The simple act of writing this blog is warming the cockles of my heart. I can’t help myself – I want to give more! How about this? The first person to register for 101 and 201 in each city, will get both workshops for FREE!
Come learn with us in 2014! Let us impart our knowledge by giving you the gifts of enlightened web development and broadened horizons!
Sign Up Today!
In general, Dojo uses the following naming conventions:
- _UpperCamelCase: mixin classes/modules
- UpperCamelCase: base classes or constructors to instantiate
- _lowerCamelCase: private/protected vars, or internal methods that may change between point releases (not typically used for a module name)
- lowerCamelCase: singletons (or normal methods when used within a module)
- _base: modules that were historically included in the default Dojo base build
The short answer is: no,
dojo/query is not guaranteed to return elements in the same order as they appear in the DOM.
query module is designed to use the DOM’s
querySelectorAll method, if available. Otherwise, it uses a CSS selector library. While
querySelectorAll does return elements in order, the selector engines provided with Dojo (
dojo/selector/lite) have been optimized for speed without strict adherence to element order. This means you may often find that they return elements in order, but this is not guaranteed.
When getting started with Dojo’s store API, it is important to realize that not all stores are created equal. Some stores, such as the
JsonRest store, communicate with a server for every request, and each of their methods return a promise resolving when the asynchronous request completes. Others, such as the
Memory store, can perform their logic synchronously, so their methods return immediate values.
This variance in the nature of store method return values can present a challenge when trying to write code that can work with any type of store. Fortunately, Dojo has tools to help in precisely this situation.
In addition to a simple, consistent, cross-browser interface to DOM events,
dojo/on provides for very convenient clean-up – the function returns a handle with a
remove method that will un-register the event listener. Clean-up concerns are not limited to DOM events, so Dojo provides the same interface for
Dojo provides many settings to configure the optimal loading and building of your application source code. We are often asked about the differences between
Here we provide a quick explanation showing common use cases for each.
Position properties on mouse events
The W3 specification for DOM events includes
screenX/Y properties on MouseEvents, but pageX/Y, layerX/Y, and offsetX/Y are non-standard properties. They are occasionally useful though and have fairly widespread browser support, even if they are a bit inconsistent.
The chief danger is with
offsetX/Y. They should report the position of the cursor relative to the origin of the closest enclosing element that is positioned, but not all browsers agree on what qualifies as a “positioned” element.
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 package 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.
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
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: