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)

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.

dojo.query supports CSS3 selectors.

Helpful websites are:

• w3.org
• 456bereastreet.com

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.

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.

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.