It's because startup() needs to be called after all the other widgets have been created, particularly the child widgets. When loading widgets from Markup, the parser knows when the last child widget of any widget is loaded.However, programatically, you'll see code like:

var foo = new MyWidget();
foo.addChild( new ChildWidget() );
foo.addChild( new ChildWidget() );
foo.addChild( new ChildWidget() );
foo.startup();

Obviously we have no way of knowing that the third addChild() call was the last one, and for something like SplitContainer (if MyWidget==SplitContainer) it would be wasteful to reformat everything each time a child was added.

This is a known bug in Mozilla.

There is a bug in the jsd (the debugging module of the Mozilla engine) dealing with code defined by an eval statement. If the code run by the eval is brought up in the debugger, it is reported as the line of code which executed the eval itself, plus the line offset within the eval. Since Dojo uses xhr + eval to load all code outside of the bootstrap, this is what you will typically see throughout your callstack when attempting to debug Dojo code in Mozilla.

IE and Safari debuggers correctly report the eval buffers when debugging, though the actual location corresponding to those eval buffers is not available to the debugger.

Pending a solution to this problem, you can try an experimental patch to the Firebug debugger which solves this problem.

Two other workarounds include manually inserting tags to load each module of source you wish to debug, explicitly loading it prior to the Dojo bootstrap, or using the debugAtAllCosts option.

The short answer:
It's harmless. This is the correct behavior when loading translated resources. To avoid the multiple hits and 404s, you need to do a build.

The long answer:
When loading translated or locale-specific material, the default mechanism is to conduct a search for the resources best matching your locale by making successive URL hits along a search path. For English, United States variant, Dojo would first look in the 'en-us' nls directory, then in 'en', then in the root for the fallback. The results would be mixed together with the most-specific ones overriding the successors, such that only the modified strings in each variant need to be present. Very often, a variant will have no content at all, so a 404 will occur.

It is not possible to predict the existence of these URLs at runtime unless special pre-processing occurs. Dojo's build process is able to flatten resources and combine them into single locale-specific files such that a single hit will fetch all of the needed code, and a second hit will fetch all translated resources. This will avoid the 404s and also optimize loading by avoiding the network latency of individual web hits.

dojo.query supports CSS3 selectors.

Helpful websites are:

• w3.org
• 456bereastreet.com

It stands for "a name that won't result in Microsoft's lawyers sending C&D's to Alex".

From Alex Russell: Actually, I was uncreative enough to name my last toolkit "netWindows" so this go-round we actually took a vote. Leonard Lin suggested "Dojo", and it won the vote. It doesn't really stand for anything.

We're different from closed source vendors because we appropriate random words out of *other* languages ;-)

Perhaps there is an extra comma at the end of a list. For example:

Or:

var foo = [ 1 , 2, 3, ];

Or:

Yes, use Microsoft Script Editor or Visual Studio

Webkit provides a debugger called Drosera and a set of tools that can help with Dojo debugging.

Is Dojo compatible with the LGPL, and could parts of Dojo be used and licensed under the LGPL later?

Short answer: yes.

Long answer: a combined work may be created out of Dojo that is distributed under the LGPL so long as you abide by the terms of our licenses. Our licenses are more permissive in every way than the (L)GPL, so the restrictions are subsumed by the subsequent restrictions of the (L)GPL. The AFL gives you sub-licensing rights, but the FSF disputes the compatibility of the AFL with the GPL. Therefore, if you choose to accept Dojo as BSD-licensed software and reproduce our copyright statement (listed below), you may use Dojo in your LGPL software.

If you use all or part of Dojo in an (L)GPL work, the copyright statement you must include is:

    Copyright (c) 2004-2007, The Dojo Foundation
    All Rights Reserved

See also:

• licensing goals
• licensing terms
• Contributor License Agreement (CLA)

Go to about:config in firefox 3
set security.file.strict_origin_policy to false and change the value of security.fileuri.origin_policy to 3 (or 4) - the default is 2.

Details for this option are outlined at http://kb.mozillazine.org/Security.fileuri.origin_policy and http://kb.mozillazine.org/Security.fileuri.strict_origin_policy

You are probably missing the Theme CSS file. Dijit is themed entirely in CSS using unique class names located in the templates themselves.

To use a Dijit theme, you must import the themename.css file. The Dijit default theme is Tundra,
and the CSS lives in toolkit_root/dijit/themes/tundra/tundra.css. Import that file using a LINK tag or style tag with an @import call:

In order for the theme to take effect, you need to utilize the cascading nature of CSS. All the rules in tundra.css are prefixed with a ".tundra" selector to prevent them from affecting other rules. You will need a class="tundra" on a parent node for the rules to apply.

The most common "parent node" is the markup parent, or <body> tag. Placing the class="tundra" on the body element applies the tundra theme to all widgets in the page.

Some widgets require the theme-class to be set on the body tag, as they append themselves there to be able to position freely. These widgets include: dijit.Dialog, dijit.TooltipDialog, dijit.Tooltip, dojox.layout.FloatingPane, among others.

The dijit.layout.ContentPane is meant to handle only HTML through it's .setHref(url) and .setContent(htmlBlock) methods. There is an alternative called dojox.layout.ContentPane which provides executeScripts capability, evaluating any inline tags it encounters.

note: putting dojo.require() calls in a remote block of HTML, and relying on executeScripts to lazy-load all your widget requirements may seem appealing, but is not guaranteed to work. It is recommended you you dojo.require() all the modules prior, most prefereably in the form of a build layer, which is a single file containing all the require code.

When using "normal" Dom Events (such as onclick, onchange, etc), you are connecting to DomNodes. These are the native events found in every browser, normalized by dojo.connect. They pass around a 'true' event object, with e.target, e.clientX/Y, and other useful information.

When using "Dijit" Events, things are slightly different.

First and foremost, the event names are `mixedCase`, to avoid conflicts and confusion. A `dijit.form.Button` has an `onClick` method (capital-C), where as a plain DomNode [button] tag has an `onclick` event.

Next, the event information isn't passed along. Dijit events are just stubs providing a normalized API for the widget functionality.

Also, Dijit events are not "real" events. They do not bubble, and are not stoppable via .preventDefault. They are used as an alert mechanism. You must connect directly to the event, using the case-sensitive name:

dojo.connect(dijit.byId("foo"), "onClick", function(){ ... });

The way Dijit's templating works, often times there is a node with an id that mimics the initial domNode you specified. For intance, there is a "real" [button] node in dijit.form.Button's template, and whatever id passed is decorated on some node in the template.

This exposes the difference between dijit.byId() and dojo.byId(). Consider the following markup:

One would dojo.connect(dojo.byId("foo"), "onclick", function(event){ ... }). You are finding a DomNode with id="foo", and applying an `onclick` listener. The above button, however, it's a Dijit. We can turn it into one very easily:

This creates a dijit.form.Button with an id of "foo" from the node with id="foo". We access the _widget instance_ by using dijit.byId:

Coincidentally, there is still a "real domNode" somewhere, with the id="foo". This is where the confusion comes in. Getting that domNode is easy:

If we connect to that node's dom Event 'onclick', things fall apart:

Because of the nature of Dom events (bubbling), any click inside of the domNode will execute the function. This is not what we want. The Dijit Button does a lot of work to fire it's synthetic `onClick` event at the right time, with [enter] or an actual [click]. This is all internal, and exposed via it's `onClick` public API.

You should not mix Dijit Events and Dom Events.

The dojo.xhr* methods are asynchronous by default. This means when you send off a request, and pass a `load:` function, the function you are running will continue executing. The `load:` function is thrown into a separate "thread" (if JavaScript had threads...) and executed when the data arrives (which could be several seconds in some cases)

The first solution is to create a closure, and use `sync:true` on the xhr call:

A more useful version of the closure would be to make it a function:

The recommend way would be to utilize asynchronous programming techniques, and the functional programming style Dojo uses.

There is also an excellent DojoCampus article explaining this further:
http://dojocampus.org/content/2008/03/14/functional-ajax-with-dojo/

This error typically indicates the lack of a tag in the response data. The variable ifd is where dojo.io.iframe stores the reference to the iframe document, used later when the iframe loads to fire the load callback. There is no "nice" warning message thrown, just a failure message thrown when trying to locate a textarea in the document.

To upload a form with an input type="file":

and a response would look like:

To use handleAs:"json", wrap the object in the textarea: