Menu

Dojo 1.9 Release Notes

User Agent Support

The following user agents have been tested and are supported in this release. If a user agent version is not listed as supported, it still may work, especially on browsers with rapid release cycles (Chrome, Firefox). Future minor releases of Dojo might include fixes to support future releases of these browsers, but it is not guaranteed. Also please note that even if IE6 and 7 code paths have not been removed, Dojo 1.9 is removing official support for those browsers.

Desktop

  • Firefox 3.6-25
  • Safari 5-6
  • Chrome 13-31
  • IE 8-11
  • Opera 10.50-12 (Dojo core only)

Mobile (dojox/mobile)

  • iOS 4.x, 5.x (Mobile Safari) and 6.x (including all Dijit widgets except Editor)
  • Android 2.2-2.3, 3.1-3.2, 4.0-4.2 (Platform browser)
  • BlackBerry 6-7 & 10 (Platform browser)
  • Windows Phone 8 (IE10)
  • Mobile compatibility on desktop browsers: IE 8-10, Firefox 4-20, Safari 5-6, Chrome 13-26

Server-Side User Agents

  • Node 0.6.X, 0.8.X

Dojo Core

dojo/node

dojo/node now properly loads CommonJS modules that depend on modules that support both CommonJS and AMD but assume that if and AMD environment is detected, don’t return anything for the CommonJS module (#16414).

dojo/parser

The parser now supports the ability to pass a context require() when parsing a document via adding it to the options hash passed during parse (#16112). This allows for the use of relative MIDs to be used, specifically in Widget templates.

Also, a widget’s markupFactory() method may now return a Promise for the new widget, and the parser will wait for that promise to resolve before calling startup() on all the widgets.

dojo/touch

There have been many improvements to dojo/touch w.r.t. touch device behavior. (Behavior on mouse devices remains the same.) Some of the fixes are:

  • works for newer devices with both touch screens and mice
  • the dojo/touch::release event consistently fires based on the node the finger was over when it was removed from the screen, consistent with mouseup behavior
  • support for Microsoft Surface (with MSPointer* events instead of touchstart/touchend/etc.)
  • dojoClick property: DOMNodes with the dojoClick property will get click events instantly rather than after 300ms, and won’t get phantom mousedown/mouseup events 300ms after the touchend event

Dijit

Mobile support in Dijit

The dijit code has been improved to work better on mobile. Dojox/mobile is still the preferred way to write mobile applications, but dijit is working better than before for writing hybrid applications to run on desktop and mobile.

dijit and dojo/domReady!

Dijit has been upgraded to be able to work with the dojo/domReady! plugin. Previously using dojo/ready was recommended, but now using dojo/domReady! is recommended. The only caveat is that if you are using the parser and have custom javascript code to run, you should run the parser manually rather than setting parseOnLoad:true.

Example usage:

define(["dojo/parser", "dojo/store/Memory", "dojo/domReady!"], function(parser, Memory){
   // script code that needs to run before parse
   myMemoryStore = new Memory(...);
   ...

   parser.parse();

   // script code that needs to run after parse
   ...
});

Server side rendering

There are two enhancements to dijit to make server side (pre)rendering of templates easier.

dijit/_AttachMixin is a new mixin to perform the data-dojo-attach-point and data-dojo-attach-event hookup normally done by dijit/_TemplatedMixin. It’s useful for custom widgets where the template is (always) expanded on the server, so on the client you just need to hookup the attach points and event listeners.

Also, dijit/_TemplatedMixin has a new _rendered parameter to the constructor, that’s useful for when standard widgets have their templates pre-expanded on the server.

Expected usage is to have markup like below on your main page:

<div class="dijit dijitReset dijitInline dijitLeft" id="widget_fname" role="presentation"
    data-dojo-type="dijit/form/TextBox" data-dojo-props="_rendered: true, id: 'fname', name: 'fname'"
        ><div class="dijitReset dijitInputField dijitInputContainer"
                ><input class="dijitReset dijitInputInner" data-dojo-attach-point='textbox,focusNode' autocomplete="off"
                        name="fname" type="text"
        /></div
></div>

dijit/_KeyNavMixin

dijit/_KeyNavMixin is a new mixin to enable keyboard navigation between a widget’s descendants. Navigation can be performed via arrow keys and HOME/END keys, and also a letter key search. dijit/Tree and dijit/form/Select are examples of widgets that extend _KeyNavMixin.

It’s similar to dijit/_KeyNavContainer but can be user for any widgets, not just subclasses of dijit/_Container.

dijit/_WidgetsInTemplateMixin

The _WidgetsInTemplateMixin supports using relative MIDs in the widget template ( #16112). For example the following is now valid:

define(["require", "dojo/_base/declare", "dijit/_WidgetBase", "dijit/_TemplatedMixin",
   "dijit/_WidgetsInTemplateMixin", "./OtherWidget"],
function(require, declare, _WidgetBase, _TemplatedMixin, _WidgetsInTemplateMixin){
   return declare([_WidgetBase, _TemplatedMixin, _WidgetsInTemplateMixin], {
      templateString: '<div><div data-dojo-type="./OtherWidget"></div></div>',
      contextRequire: require
   });
});

Also, dijit/InlineEditBox and dijit/_editor/plugins/FontChoice were updated to take advantage of this new feature.

Note Because of the synchronous nature of the widget lifecycle, you still have to require in any modules used in the template, as the auto-require feature will not work properly with widgets.

dijit/a11yclick

The a11yclick module was updated with new synthetic events “press” and “release” that fire for mousedown/mouseup, touchstart/touchend (or Microsoft equivalents), or keydown/keyup. They only call the listener when the events will trigger a click. I.E. for keyboard, it’s the SPACE or ENTER key, and for mouse, it’s the left mouse button.

Many modules were updated to take advantage of this, including _CssStateMixin (which now show feedback while pressing a button via keyboard, by showing the button in its active state between keydown and keyup.

Also, the allyclick module was updated to support the keyboard equivalent of mouse clicks with modifiers. I.E. an app can setup a listener on a11yclick.click, and regardless of whether the user does a ctrl-left-mouse-click or a ctrl-ENTER key, the listener will be called where evt.ctrlKey == true.

dijit/BackgroundIframe

There’s now a “config-bgIframe” has() flag that can be used to explicitly turn on/off the background iframe behind popups that’s useful when a page contains applets, and also for older versions of IE with the bleed through select problem.

Usage is:

<script type="text/javascript" src="../../dojo/dojo.js"
  data-dojo-config="has: {'config-bgIframe': true}"></script>

It can also be specified as a build parameter in the staticHasFlags section.

By default it’s turned on for desktop pages, but turned off for mobile.

dijit/Declaration

Declaration now supports <script type="dojo/aspect">, in addition to the <script type="dojo/connect"> syntax which is now deprecated (and will be removed for 2.0). For example:

<div data-dojo-type="dijit/Declaration" data-dojo-props='widgetClass:"MyWidget"'>
        <script type="dojo/aspect" data-dojo-method="startup" data-dojo-advice="before">
                // ...
        </script>
</div>

dijit/Dialog

There’s a new closable property that can be set to false, to hide the [x] icon for closing the dialog and prevent the ESC key from closing it. Example usage:

<div id="unclosable" data-dojo-type="dijit/Dialog" title="Unclosable Dialog" data-dojo-props="closable:false">
        <div class="dijitDialogPaneContentArea">
                This dialog has no close icon and the ESCAPE key won't close it.  You need to use the buttons.
        </div>
        <div class="dijitDialogPaneActionBar">
                <button id="unclosableSubmit" data-dojo-type="dijit/form/Button" type="submit">OK</button>
                <button id="unclosableCancel" data-dojo-type="dijit/form/Button" type="button"
                                onClick='dijit.byId("unclosable").onCancel();'>Cancel</button>
        </div>
</div>

dijit/Fieldset

There’s a new Fieldset widget, which is a collapsible fieldset similar to dijit/TitlePane. Example usage:

<div id="tp2" data-dojo-type="dijit/Fieldset">
    <legend>My legend</legend>
    Click legend to close me.
</div>

dijit/Menu

There’s a new RadioMenuItem widget that (similar to CheckedMenuItem) can be used to make menus with radio button choices, only one of which is selected at a time. For example:

<div id="menu" data-dojo-type="dijit/DropDownMenu">
        <div id="g1r1" data-dojo-id="g1r1" data-dojo-type="dijit/RadioMenuItem"
                 data-dojo-props="group: 'g1'">small</div>
        <div id="g1r2" data-dojo-id="g1r2" data-dojo-type="dijit/RadioMenuItem"
                 data-dojo-props="group: 'g1', checked:true">medium</div>
        <div id="g1r3" data-dojo-id="g1r3" data-dojo-type="dijit/RadioMenuItem"
                 data-dojo-props="group: 'g1'">large</div>
</div>

Also, there’s a new passivePopupDelay property on MenuBars (and also Menus) that, when set to a finite value, merely hovering the menu will open the dropdown. Usually the user needs to click the menu to show the drop down menu. Example usage:

<div data-dojo-type="dijit/Menu" data-dojo-props='passivePopupDelay: 500'>
        ...
</div>

dijit/Tree

dijit/tree/ObjectStoreModel now supports a labelType parameter like dijit/form/ComboBox, allowing Tree labels to be HTML rather than plain text. The default is still plain text. Example usage:

require([
    "dojo/store/Memory", "dijit/tree/ObjectStoreModel", "dijit/Tree", "dojo/domReady!"
], function(Memory, ObjectStoreModel, Tree){

    // Create test store, adding the getChildren() method required by ObjectStoreModel
    var myStore = new Memory({
        data: [
            { id: 'world', name:'<i>rich text</i>The earth', type:'planet', population: '6 billion'},
            ...
        ],
        getChildren: function(object){
            return this.query({parent: object.id});
        }
    });

    // Create the model
    var myModel = new ObjectStoreModel({
        store: myStore,
        labelType: "html",
        query: {id: 'world'}
    });

    // Create the Tree.
    var tree = new Tree({
        model: myModel
    });
    tree.placeAt(win.body());
    tree.startup();
});

DojoX

dojox/mobile

Features

  • dojox/mobile data-aware lists now support an itemRenderer property allowing to change the type of ListItem instances created by the list.
  • dojox/mobile list widgets now provide filtering capabilities. For details, see dojox/mobile/FilteredListMixin.
  • dojox/mobile editable list widgets now have callback functions on user actions. For details, see dojox/mobile/RoundRectList.
  • Internet Explorer 10 is now supported “natively” (that is, without compatibility code and CSS): since IE10 supports CSS3 transitions, animations and gradients, compatibility mode is disabled for IE10, and Dojo Mobile uses the non-prefixed CSS3 properties supported by IE10 in addition to the webkit-prefixed properties.
  • A new Windows theme is available (in dojox/mobile/themes/windows/) and provides a look and feel inspired by the Windows 8 / Windows Phone 8 “Metro” interface. If you use the dojox/mobile/deviceTheme module, the Windows theme is selected by default on Internet Explorer 10 (so, for example, on Windows 8 tablets and on smartphones running Windows Phone 8). Note: the Windows theme is marked as experimental for now, because some widgets have a very different layout, so using it may disturb the layout of the application.
  • FormLayout container: a responsive container for creating mobile forms.
  • The user agent tests that were previously done in dojox/mobile/sniff have been moved to dojo/sniff, so the use of dojox/mobile/sniff is deprecated, You should now use dojo/sniff instead. The dojox/mobile/sniff module is still present in this release for compatibility, but it will be removed in a future release.
  • The has("ios") feature test defined in dojo/sniff now returns the iOS version (instead of a Boolean). In previous versions, you used has("iphone") to detect any iOS device (iPhone, iPad or iPod). You should now use has("ios") instead. The dojox/mobile/sniff module still sets the "iphone" feature to the iOS version on all iOS devices for compatibility, but in future releases it will be set only for an iPhone device.
  • The dojox/mobile/RoundRectStoreList and dojox/mobile/EdgeToEdgeStoreList widgets now support updating existing store items. When a put operation is performed on the store, the corresponding list item is updated with the new properties of the store item. A new onAdd method has been added to dojox/mobile/_StoreMixin to better distinguish add and put operations.
  • To address performance problems with very long lists in scrollable views, a new dojox/mobile/LongListMixin module has been added. This module can be mixed in any Dojo Mobile list (dojox/mobile/RoundRectList, dojox/mobile/EdgeToEdgeList, and their data-aware variants) using data-dojo-mixins="dojox/mobile/LongListMixin". This will transparently enable listeners on the scrollable view to keep only a subset of the items in the DOM, which will significantly speed up scrolling.
  • A subset of widgets (Button, CheckBox, Heading, ListItem, RadioButton, Slider, Switch, ToggleButton, and View) can now be templated. For details, see Templating dojox/mobile widgets.
  • Support for HTML5-compliant attributes has been introduced:
    • Fixed header and footer: for headers or footers which are not widgets, the attribute data-mobile-fixed can now be used in markup. For backward compatibility, the attribute fixed is still supported but it is deprecated and will be removed in a future release.
    • ListItem: the attributes data-mobile-layout and data-mobile-prevent-touch can now be used in markup on children which are not widgets. For backward compatibility, the attributes layout and preventTouch are still supported but are deprecated and will be removed in a future release.
    • Carousel: for the lazy loading of children of type SwapView, it is no longer necessary to use the non-HTML5 compliant attribute lazy. Carousel now dynamically extends SwapView adding to it the property lazy, which can now be specified in markup using the data-dojo-props attribute. For backward compatibility, the attribute lazy is still supported but it is deprecated and will be removed in a future release.
  • Building themes: A new folder dojox/mobile/themes/utils now contains scripts and documentation for building mobile themes. The number of required .less files for a particular theme has been drastically reduced.
  • The ‘Custom’ theme is now generated from 2 main colors, facilitating the creation of a new theme based on arbitrary colors.
  • The dojox/mobile/TabBar widget now supports resizing its children so that they evenly fill all the space available in the bar. This is done by setting the new attribute “fill” to the value “always”.
  • “beforescroll” and “afterscroll” events added to scrollable widgets (dojox/mobile/ScrollableView, ...). The beforescroll event handler can return false to cancel the scroll. See the dojox/mobile/ScrollableView API doc for more informations on these new events.
  • Dojo Mobile sets the dojoClick property on the document body, so all Mobile widgets benefit from the new dojo/touch features (in particular, click events are fired instantly on touchend events). See the dojo/touch section in Dojo Core above.
  • New Android Holo dark theme used by default on Android 3.x and 4.x devices. For backward compatibility, you can force ‘Android’ theme on all Android devices by configuring deviceTheme:
<script src="../deviceTheme.js" data-dojo-config="mblUserAgent:navigator.userAgent.match('Android')?'Android':null">

Incompatibilities

  • Using the dojox/mobile/scrollable.js module without Dojo is not supported any more. The dojostub.js module, which was provided in dojox/mobile/tests to emulate some Dojo features and let you use scrollable.js outside of Dojo, is no longer provided. The tests for this use case are also removed.
  • The endTransition method of the dojox/mobile/TransitionEvent class has been removed since it was never called by the dojox/mobile framework.
  • dojox/mobile/sniff module does not anymore require dojo/_base/sniff but dojo/sniff. This means you can’t use anymore isXX methods (such as isIE); you should use has flags instead (such as has("ie")).
  • As a consequence of the new support for templating on some widgets (see above), old code that was already attempting to mix dijit/_TemplatedMixin into mobile widgets may not work any more. The new behavior is that, when a widget is templated, Dojo Mobile assumes that the template contains the whole widget contents, and no children nodes will be created by the widget code. For example, in a templated dojox/mobile/ListItem, the template must contain a labelNode attach point (whereas, in 1.8, the label node was always created internally). So, old code using templates with mobile widgets should be modified and the necessary attach points should be added to the templates.

dojox/charting

Features

  • Threshold indicators (dojox/charting/plot2d/Indicator) can now easily be drawn on top of the chart.
  • Axis (dojox/charting/axis2d/Default) now supports rendering ticks inside of the plot area instead of outside of the axis. For that specify a negative length for the ticks.
  • Mouse indicator action (dojox/charting/action2d/MouseIndicator) now supports over mode in addition to mouse drag. The mouse indicator can also be further customized (ability to remove the label, ...).
  • Grids (dojox/charting/plot2d/Grid) now support grid stripes in addition to grid lines.
  • Ability to render labels on data points for Bubble/Columns/Default/Scatter plots by setting labels property to true.
  • Charting bidi features (bi-directional text and mirroring) can be enabled using the dojo-bidi has flag you should not use BidiSupport modules anymore. See dojox/charting migration for details.
  • Charting now supports bidi mirroring. You can perform mirroring by calling myChart.setDir(“rtl”) once bidi features have been included using dojo-bidi.
  • Most plots now supports a filter property which allows to apply an SVG filter to the plot elements when using gfx SVG renderer.

Incompatibilities

  • Tooltip on stacked plots now display the value of the hovered data point not of the stacked value. One can go back to previous behavior if needed by customizing the text function of the Tooltip action.
  • Tooltip, highlight and magnify actions are not anymore hardcoded into the spider plot (dojox/charting/plot2d/Spider). One needs to explicitly set them up on the plot to get them activated. See dojox/charting migration for details.

dojox/app

Features

  • dojox/app now provides a build system extension that allows you to easily build your application from the config file.
  • One can now use the type property for a view in the config file to specify alternate view class extending dojox/view/ViewBase.
  • Configuration of views now accept a nls property to specify an AMD internationalization root module for a view.
  • Custom Layout controller support is available with a dojox/app/controllers/LayoutBase which can be extended with a custom layout controller.
  • Support for a constraint setting on a view in the config has been added, which will add data-app-constraint to the domNode for the view, and place the view into the specified constraint (or region).
  • A new BorderLayout controller has been provided, which uses a dijit/layout/BorderContainer to layout views, and uses constraint settings on views in the config to determine which constraint (or region) a view should be placed into.
  • One can now specify an alternate transition animation function by using the transit property in top level section of the configuration file.
  • The activate & deactivate function of the view lifecycle now accept two arguments:
    • respectively the previousView or nextView for the current view at its position
    • a raw data object that can be passed from one view to another by specifying a data attribute in the transition options.
  • Support was added to allow multiple views to be included in the DefaultViews in the config as well as on transitions and the url used in the transition. This allows multiple views to be displayed with different constraints (or regions) at the same time. It is also now possible to transition views in regions other than the center. To specify multiple views the view names would listed separated by a “+” for example “view1+view2” or “view1,subviewA+view2”. Support has also been added to be able to use a “-” to hide a view. So if “view1+view2” are displayed and a transition is requested for “view3-view1” then view3 would be displayed (replacing view2 assuming they have the same constraint) and view1 would be hidden.
  • Support was added to allow view specific params. To specify params for a specific view the params must contain the view name with the view specific params set with the view name, for example:
MainOption1: function(e){
        var views = "navLeft+mainCenter+lastRight"
        var params = {"mainCenter":{'mainSel':"MainOption1","tparam1":"tValue1"}};
        var transOpts = {
                title: views,
                target: views,
                url: "#"+views,
                params:params
        };
        new TransitionEvent(e.target,transOpts,e).dispatch();
},
Features (continued)
  • A new config setting for “transition” has been added to set the transition animation type to use for the view transition. If a “transition” is set on a view or parent it will override the transition set on the transitionEvent or the defaultTransition in the config.
  • Observable support for stores via the config has been added. Setting “observable”: true on a store will have the store wrapped in a dojo/store/Observable.
  • dojox/app is changing it’s recommendation for the file structure used for an app. The recommendation now is to place the “controller” (.js files) and the “template” (.html files) in the same folders for related parts of the app. This makes it much easier to reuse code between apps.
  • It is no longer necessary to set a view controller to “none” when the view does not use a controller. Now when view does not set a controller in the config, no controller will be loaded for the view.
  • In order to make it easier to access the loaded stores from a view, dojox/app will now have access to the loaded stores via a loadedStores object on the view. Support has also been added to allow stores to be defined for a specific view in the config, previously stores could only be created globally for the application.
  • dojox/app now provides “has” test support for the config file, so there is no longer a need for multiple configs for an app. In the example below dojox/app/main would process the has sections and merge the appropriate sections into the config. Properties set on the config at the same level as the has will be replaced by the value set in the has section, and items in an array will be added to config array with the same name and at the same level as the has section.
// The app would have code like this:
require(["dojo/text!"+configurationFile], function(configJson){
        var config = json.fromJson(configJson);
        var width = window.innerWidth || document.documentElement.clientWidth;
        if(width <= 600){
                has.add("phone", true);
        }
        has.add("ie9orLess", has("ie") && (has("ie") <= 9));
        Application(config);
});


// The config would include something like this:
"has" : {
        "phone" : {
                "defaultView": "configuration"
        },
        "!phone" : {
                "defaultView": "configuration+TestInfo"
        },
        "ie9orLess" : {
                "controllers": [
                        "dojox/app/controllers/HistoryHash"
                ]
        },
        "!ie9orLess" : {
                "controllers": [
                        "dojox/app/controllers/History"
                ]
        }
},

Incompatibilities

  • data-app-region has been changed to data-app-constraint.
  • The property name used in the config for the view’s .js file has been changed from “definition” to “controller”, config files will have to be updated to use “controller” instead of “definition” in the view.
  • The option to be able to load a default controller for a view (when the controller is not set) has been removed. The view must specify a controller if the controller is to be loaded. If the view does not have a controller module to load, it should not set a controller. Setting the controller to “none” is no longer supported.
  • Since “+” and “-” can now be used to indicate multiple views on a transition, those characters are no longer allowed in a view name.
  • The events used in the Layout controllers have changed from layout -> app-initLayout and select -> app-layoutView, and the other events used by dojox/app have also been changed to have an app- prefix for example, load -> app-load, init -> app-init, domNode -> app-domNode, and transition -> app-transition.
  • zIndex is no longer automatically set on views depending upon whether they are in the center or not. In the past the zIndex was automatically set higher on the left pane of a tablet view to avoid having the transition for the center show over that left pane.
  • In 1.8 dojox/app would automatically require a model and mvc controller if it was listed in the config and not included in the list of dependencies. In 1.9 the model and mvc controller will need to be listed in the dependencies. For example:
"dependencies": [
        "dojox/app/utils/simpleModel",
        "dojox/app/utils/mvcModel",
        "dojox/mvc/EditStoreRefListController",
        // ...
]
Incompatibilities (continued)
  • In 1.8 dojox/app would automatically include the Load, Transition and Layout controllers, unless “noAutoLoadControllers” was set to true in the config. In 1.9 the controllers are no longer automatically loaded, and the noAutoLoadControllers option has been removed. So the config must include the necessary controllers. For example:
"controllers": [
        "dojox/app/controllers/Load",
        "dojox/app/controllers/Transition",
        "dojox/app/controllers/Layout",
        "dojox/app/controllers/History"
]

dojox/calendar

Features

  • Better support of asynchronous stores. Interactive event creation is now working with asynchronous stores (event is added to store at the end of the gesture). Event renderers are notified of the current store state (being created but not added yet to store, being added/updated, in store). An example is available (tests/asynchStore.html)
  • New properties have been added to further customize the the row header of the column view.
  • Grid cells can now be customized either programmatically by providing a custom function (styleGridCellFunc property of views) or by CSS (ex .dojoxCalendarGrid .Wed.H12 { ... } ). See tests/calendarStyleGridCell.html and tests/calendarStyleGridCellCSS.html.
  • Query options to be set when querying the store can now be specified on the calendar using queryOptions property.

Incompatibilities

  • In 1.8, the Date constructor was used as last resort to decode a Date string. In 1.9, as it is not reliable, the Date constructor is not used, and time.newDate() will throw an error if parameter is string and it cannot be decoded using ISO decoder (dojo/date/stamp).
  • In 1.8, the renderers life cycle events (onRendererXXXX) have the renderer as parameter. In 1.9, an event is passed as parameter. This event will provide the renderer but also the view where this renderer is used and for “rendererCreated” and “rendererReused” events the data item displayed by this renderer.
  • The ColumnView.styleGridColumn has been renamed into styleGridCell and two arguments have been added.
  • The calendar is now complying with the resize policy of Dojo. If the calendar, and especially the Matrix View, is not in a Dijit container or a Dojo mobile container, the application developer must call the resize() method of the calendar (or the view if used as standalone).
  • In 1.8, the itemEditEnd event item property was inconsistent with the other editing events because it was representing the store item instead of the render item. In 1.9, each editing event is containing two properties:
    • item: The render item. To change editing behavior set the startTime and/or endTime of this object.
    • storeItem: the store item. You may want to access some properties of the store item to determine the editing logic.
    • The tests/editing.html shows an example.
  • In 1.8, the dojox/calendar/Calendar methods called isItemEditable, isItemMoveEnabled and isItemResizeEnabled took as first parameter the internal render item which that was not useful. Now the store data item is passed.

dojox/gfx

Features

  • Add dashed stroke support to canvas renderer. If the browser implements the (new) HTML5 dash api (context2d.setLineDash()) then the gfx renderer uses it. Otherwise, it relies on a custom (canvas- specific) implementation.
  • Extend batch mode support to canvas renderer. When enabled, repaint requests are suspended for the target container until the current batch is closed via a call to closeBatch().
  • Add SVG filter support. The dojox/gfx/svgext module adds a new Shape.setFilter() method to set a filter object on a shape. A filter objects should define a set of properties to configure the filter (like x, y, etc.) and the list of filter primitives (as an array) that make this filter, as specified by the SVG specification (http://www.w3.org/TR/SVG/filters.html). In addition, the new dojox/gfx/filters module defines a minimal convenient API to write filter objects as well as a set of predefined, ready-to-use filters. See dojox/gfx/tests/test_filter.html for an example of this new API, and the Dojox Gfx reference guide for more information. Note: IE9 does not support SVG filters.
  • The gfx.shape.Text class implements getBoundingBox() (all renderers).
  • Add gfx.shape.Shape.on() and Surface.on() methods. The connect()/disconnect() API is deprecated.

Incompatibilities

  • The gfx registry API (gfx.shape.byId(), gfx.shape.getUID(), gfx.shape.register(), gfx.shape.dispose()), is now optional, and is disabled by default. If an application uses it, it must explicitly require the dojox/gfx/registry module.

dojox/treemap

  • Query options to be set when querying the store can now be specified on the treemap using queryOptions property.

dojox/form/manager

  • dojox/form/Form now inherits from dijit/_WidgetsInTemplateMixin.
  • The dojox/form/manager package has been converted to use dojo/on instead of dojo/connect (#16288) and the test pages have been made more robust and converted to AMD (#16289).
  • The observer attribute used by dojox/form/Manager has been changed to the HTML5-valid data-dojo-observer (#13449).

dojox/form/Uploader

  • dojox/form/Uploader is now AMD compatible and works declaratively in HTML markup
  • The AMD update necessitated discarding the previously implemented plugin system. All dependencies are loaded by default. Using the deprecated plugin style should throw warnings in the console. The force parameter is still used to choose between HTML5, Flash or IFrame.

dojox/date

A new alternate calendar system, Um AlQura (Hijri) calendar, was added. See dojox/date/umalqura

Util

DOH

Support added for returning a dojo/promise/Promise or dojo/Deferred from a test fixture. Before, you could only return a doh.Deferred or a dojo/_base/Deferred.

Migration Notes

dijit/Calendar

To avoid accessibility issues, the dijit/Calendar template was changed so that the month name and arrows, plus the previous, current and next year, are not contained within the <table> node. CSS was correspondingly changed.

dijit/_Container::addChild()

In 1.8, the behavior of dijit/_Container (and subclasses) .addChild() method was undefined if some of the _Container.containerNode direct children were plain DOM nodes, rather than widgets.

In practice though, when addChild(widget, n) would count to the n‘th position, it would skip over the plain DOMNodes and only include the child widgets in the count.

Further, if the existing child widgets were not direct children of this.containerNode, then .addChild() would tend to place the new widget as a next or previous sibling of an existing child widget, rather than as a direct child of this.containerNode.

In 1.9, parent.addChild(widget, n) places widget.domNode as the n‘th DOMNode child of parent.containerNode, just like dojo/dom-construct::place() does.

If your application was calling parent.addChild() on a widget that contained plain DOM nodes, and depending on the undefined behavior listed above, you may need to update your logic.

dijit: keypress to keydown

For performance, a number of widgets were changed to use the native keydown event rather than the synthetic (and deprecated) dojo/_base/connect._keypress event.

This include changes to the template like data-dojo-attach-event="onkeydown: _onKeyDown" rather than data-dojo-attach-event="onkeypress: _onKeyPress", and in the class definitions code renaming _onKeyPressed() to _onKeyDown(), and accessing evt.keyDown rather than evt.charOrCode.

Changed widgets:

  • Menu (dijit/templates/Menu, DropDownMenu.js, MenuBar.js)
  • Slider
  • NumberSpinner
  • InlineEditBox (onkeypress handler removed, onkeydown not added)
  • StackContainer, StackController, TabController, ScrollingTabController
  • AccordionContainer (technically, AccordionButton)
  • BorderContainer
  • Editor

Note that _TextBoxMixin still creates it’s own normalized event object defining evt.charOrCode, and passes it to ._onInput().

dijit Template Changes

dijit/templates/InlineEditBox.html and dijit/form/robot/DropDownBox.html were changed in this release.

If you have subclasses of InlineEditBox, ComboBox, FilteringSelect, or DateTextBox that have modified those templates, you may need to update your templates.

Also, a number of widget templates were changed from using <img> nodes to <span> nodes for icons. If you have custom CSS that depends on the img tag name, you probably need to change it.

dijit/Editor

If you are creating Editor widgets programatically, be sure to call startup() on them.

StackContainer, TabContainer

There was a wrapper div added around each StackContainer child for accessibility reasons. Also, pane2button is now a function rather than a hash.

dijit/Tree

Tree::persist was changed to false by default. Also, persisting a Tree no longer saves/restores which TreeNodes are selected, but just which TreeNodes are open.

dijit bidi support

Dijit bidi functionality is not enabled anymore by the dijit/_BidiSupport module. Instead you should be using the dojo-bidi flag.

Replace code like:

<script src="dojo.js"></script>
<script>
  require(["dijit/Dialog", "dijit/_BidiSupport"], ...);
</script>

by

<script src="dojo.js" data-dojo-config="has:{'dojo-bidi': true}"></script>
<script>
  require(["dijit/Dialog"], ...);
</script>

dojox/charting migration

Tooltip, highlight and magnify actions are no longer “hardcoded” into the spider plot (dojox/charting/plot2d/Spider). The need to be explicitly setup on the plot to utilize them, for example:

new Tooltip(spiderchart);
new Highlight(spiderchart);
new Magnify(spiderchart, "default", {duration: 800, scale: 1.5});

Charting bidi features are not enabled anymore by the BidiSupport and BidiSupport3D modules. Instead you should be using the dojo-bidi flag.

Replace code like:

<script src="dojo.js"></script>
<script>
  require(["dojox/charting/Chart", "dojox/charting/BidiSupport"], ...);
</script>

by

<script src="dojo.js" data-dojo-config="has:{'dojo-bidi': true}"></script>
<script>
  require(["dojox/charting/Chart"], ...);
</script>

DOH

The doh object used to have all the dojo/_base methods, for example dojo.forEach() was accessible via doh.forEach(). This is no longer the case. Those methods should be accessed via the dojo global, or better yet via AMD require of the proper module (dojo/_base/array in this case).

Error in the documentation? Can’t find what you are looking for? Let us know!