• Calendars
• File Cabinets
• Knowledge Base
• Photo Pages
• Spreadsheets
• To-Do Lists

This is page contains all the information you may need to porting your code from dojo 0.3 to dojo 0.4.1

Core

DomContentLoaded

Widgets are instantiated and functions passed to dojo.addOnLoad() are run earlier than in 0.3.1, before the page's images and CSS finish loading.  As a result of that:

• All images on the page should have height/width specified in the HTML itself.  (I think this is particularly important for images embedded in the Button widget.)
• (0.4.0 only, see below for 0.4.1 changes)For Firefox, if you have large images on your page, and the page hangs during downloading, you need to set the delayMozLoadingFix flag:

      <script type="text/javascript">
          /* since we are loading big images (actually, background-images), need to workaround the mozilla bug */
  
          var djConfig = {isDebug: true, delayMozLoadingFix: true };
      </script>
      ....
      
  

• For 0.4.2, the above behavior was changed for Firefox ONLY. All other browsers continue to use the the DOMContentLoaded (or the browser-specific equivalent) to kickoff  Dojo widget initialization. Due to a nasty bug in the Firefox 2 codebase, Dojo initialization on that platform is now performed from the global onload event. It's possible to switch to the DOMContentLoaded by setting the djConfig.enableMozDomContentLoaded flag to true.
  

dojo.dom

dojo.dom.removeNode (or dojo.html.removeNode) shall be revisited in your code: if the node is never used, then dojo.dom.destroyNode (or dojo.html.destroyNode), introduced in 0.4.1, shall be used to prevent IE memory leaks. If you do need to use that node, then removeNode shall be used. However, in order to prevent IE memory leaks, one of the two below shall be true:

• The node is inserted back to the document, or
• Call destroyNode on the node before the page unload (see DataPicker.js for an example)

All occurence of replaceNode should also be checked: if the replaced node is no longer needed, destroyNode should be called on it.

dojo.html

The dojo.html module was refactored; lots of changes, but centering around splitting stuff into multiple resources (aka javascript source files), and about combining functions, so that (for example) getHeight() and getWidth() are combined into a getSize() function that returns a {width: 500, height: 300} like object.

DnD

Many bugs were fixed in the DnD? code but it might affect people subclassing from the stuff in HtmlDragMove?.js etc.

Also, for DnD of absolutely positioned objects, they must be positioned using "left" and "top", not using "right" or "bottom".

Events

Should start using the "onKey" event rather than "onKeyPress" or "onKeyDown", which are still supported but aren't portable across browsers.

Private Functions

Many private function's names were changed to have an underscore.  (Ex: setLabel() --> _setLabel()).   In theory this shouldn't affect users but maybe some people were using those private functions.

Dojo.require/Dojo.provide

Each javascript source file now has have exactly one dojo.provide() call, corresponding to the file name, so your source code must have one dojo.require() call for each resource (aka javascript source file) that it needs to load.  (Previously this was ambiguous.)

For example, if you are using DropDownButton?, you should do dojo.require("dojo.widget.Button"), since that widget is defined in Button.js.

But note also that you no longer need to have dojo.require() calls for widgets.  You can do dojo.require("dojo.widget.*") instead, and it will pull in the right resources automatically.

Widget

Namespaces

• dojo.setModulePrefix() has been replaced by dojo.registerModulePath() for registering new modules.  Custom widgets should now be registered in their own XML-style namespace for use in DojoML and createWidget() rather than put in the standard dojo: namespace.  The dojo: namespace is still the default when used with the dojoType attribute or with createWidget().  See the book for more information on widgets and namespaces.

General

• All widgets have a "disabled" attribute that works like the same way as the disabled attribute works in IE, FF, etc.  In particular this means that you should never say <div ... disabled="false">, because that actually sets disabled to true.  (Confusing, but it's the defacto standard.)  Same for "checked".   You should say in HTML <div ... disabled>, and in XHTML  <div ... disabled="disabled">
  

AccordionContainer

• Revamped AccordionContainer to work like LayoutContainer, so now the parent AccordionContainer widget is necessary (and you should explicitly set the size), and the AccordionPane widget is deprecated.  See the test_AccordionContainer.html for example.
  

Combobox

• The API for the data provider was unclear.  (Specifically the API the data providers supported did not match the way that ComboBox was actually calling the data providers.)   Reworked those two to match each other.  If you've written a custom data provider you'll have to update it to match the new pattern in Combobox.js
  

Dialog

• If you want the dialog to close by clicking anywhere on the background, you now have to set closeOnBackgroundClick="true"
  

TabContainer

• selectedTab parameter deprecated in favor of selectedChild
• RemoteTabController deprecated in favor of TabController
• If you have a TabContainer with the tabs set to display:none, then you should start using a PageContainer instead.  (That's the purpose of PageContainer)