It's because the template file is no longer a tree; it's a forest (there are two top level nodes, a comment node and the real node). You can "goose" the widget system by setting dojoAttachPoint="domNode" on what you'd *like* to be the visible root of your widget. That'll work regardless of how many peers or parents that widget has. It's also a great way to implement state-only widgets (state1 -> state2 -> state3 -> etc.).

Often this is caused by closing tags with /> syntax. For example:

    <script src="dojo.js" />
    <div dojoType="DatePicker" />

    <script src="dojo.js"></script>
    <div dojoType="DatePicker"></div>

Are they any HTML references indicating that only the explicit closing tag form works?/p>

• http://www.w3.org/TR/xhtml1/#C_3
• http://www.w3.org/TR/html4/interact/scripts.html#h-18.2.1

• http://www.w3.org/TR/html4/struct/text.html#h-9.3.2.1

I've downloaded the kitchen sink, I've loaded the demo Fisheye page and the I tried copying it into my own page. I get:

Error: Could not load "dojo.widget.FisheyeList"; last tried "__package__.js" 

Did you copy just the dojo.js file? You will need the src directory too. The widgets are loaded on demand in all builds distributed from dojotoolkit.org. It's possible to build widget resources into a dojo.js file, but that will require a custom build.

This might be simple, but I can't figure it out: How can I write a self-contained widget that handles its own callback from a dojo.io.bind() call? Specifically, how can I bind the callbacks (load, error) from a dojo.io.bind call to an object's method?

You could use:

 	
this.clicked = function() {
	dojo.io.bind({
		url: this.actionURL,
		method: 'get',
		content: {
			id: this.rowId,
			field: this.dbField,
			value: this.checked
		},
		load: dojo.lang.hitch(this, this.clickSuccess)
	});
}

Dojo can URL encode the arguments list for you, like so:

To receive JSON data, just do:

	
var myVeryCoolObject = null;
var bindArgs = {
	url:  "foo.js",
	type: "text/javascript",
	load: function(type, data, evt){
		myVeryCoolObject = data;
	}
};
dojo.io.bind(bindArgs);

I want to do a simple procedure, where a user submits a form from the front-end using POST and a success message comes back in a specified div id without page-refresh. How do i do that using dojo.io.bind?

As of Dojo 0.3.0, you can use the dojo.io.updateNode method to simplify the case where you want to do innerHTML replacement.

dojo.io.updateNode("target_div_id", {
	formNode: dojo.byId("your_form_id"),
	method: "post"
});

Using formBind like this also helps to prevent memory leaks since the replaced content will have dojo.event.browser.clean() called over it prior to removal.

Regular-old dojo.io.bind() supports submitting forms and will take it's configuration from the from unless you over-ride it.

dojo.io.bind({
	formNode: dojo.byId("your_form_id"),
	load: function(type, data, evt){/* do something with the return */}
});

In this example we expect the form node that is passed to have action and method properties defined which will determine the url and method arguments to the bind call.

Starting with the 0.2 release, you can use namespaces for attributes and class declarations to declare the dojo type. This feature was removed after the 0.4 release due to performance issues in the parser. Going forward, supplemental DTDs are required for validation.

When you call dojo.require("dojo.foo.bar.baz"), Dojo tries to load the following files, in this order:

1. src/foo/bar/baz.js
2. src/foo/bar.js
3. src/foo/bar/__package__.js
4. src/foo.js
5. src/foo/__package__.js

When the ".*" suffix is added, Dojo searches for a "__package__.js" file *first*. When you call dojo.require("dojo.foo.bar.baz.*"), Dojo tries to load the following files, in this order:

1. src/foo/bar/baz/__package__.js
2. src/foo/bar/baz.js
3. src/foo/bar/__package__.js
4. src/foo/bar.js
5. src/foo/__package__.js
6. src/foo.js

Given a folder structure like so:

dojo/
turbo/
     foo.js

...you can use the setModulePrefix method to "register" the namespace for use with the Dojo loading system, like so:

   dojo.setModulePrefix("turbo","../turbo"); // relative to the dojo root
   dojo.require("turbo.foo");

Let's say you have this folder structure:

projects/
	dojo/
		buildscripts/
	foo-project/
		src/
			foo/
				Bar.js

...where projects/foo-project/src/foo/Bar.js contains:

    dojo.provide("foo.Bar");
    foo.Bar=function(){ ... }

...in your custom profile.js script, you need to specify the module prefixes, something to this effect:

var dependencies = [
	"dojo.io.IO",
	"dojo.event.*",
	"dojo.io.BrowserIO",
	"dojo.xml.Parse",
	"dojo.webui.widgets.*",
	"dojo.webui.DomWidget",
	"dojo.animation.*",
	"foo.Bar"
];

dependencies.prefixes = [
	// this HAS to be relative to DOJO_HOME/ folder
	['foo', '../foo-project/src/foo']
];

load("getDependencyList.js");

• Eclipse
• MyEclipse
• JSEclipse

If your project uses Subversion for your source code version control, and you need to bundle the dojo toolkit into your project, you can use the Subversion "externals" feature to include dojo "by reference" instead of "by copy". For more info see the subversion manual. Or if you're using TortoiseSVN, see section 5.2.4 of PDF TortoiseSVN manual.

Yes. There's an optional flag available called "debugAtAllCosts" that pulls files in the "expensive" way, in order to provide exactly this. It requires that you include one more line in your usage. Here's how you might use it:

<script>
    djConfig = {
	isDebug: true,
	debugAtAllCosts: true
};
</script>
<script src="/path/to/dojo/dojo.js"></script>
<script>
	// dojo includes here
	dojo.require("dojo.myModule");
	dojo.hostenv.writeIncludes(); // this is a new line
</script>

Once you've structured your code this way, if you open up Venkman, you'll see all the constituent files listed and you can then set breakpoints.

Is there a way to attach a css style to the dojo debug messages? In my case they always appeared behind some div, so i couldnt see them. How can i specify where they appear?

In djConfig, you can specify which element they are appended to by providing an id of that element: i.e.:

  var djConfig={
	isDebug:true,
	debugContainerId:"dojoDebug"
};

for <div id="dojoDebug"></div>

Sometimes dojo's error messages about syntax errors are really cryptic due to how dojo loads files via dojo.require(); however, you can get a better message by simply directly including the js file with the <script> tag.

There's also a lint program that Brian has recommended.

When you install Firefox, you should select the option for DOM inspector. This tool shows you the DOM tree after the dojo widgets have been expanded. It's indespensible.

There are similar tools for IE. We recommend Microsoft's own Developer Toolbar.

HTTP monitors and debuggers are tools that monitor the HTTP traffic to/from the server; they are essential for ajax debugging.

For Firefox the answer is short, simple, and cannot be understated. http://getfirebug.com

For WinXP there is a handy tool called Fiddler; it configures itself as proxy and it's a one click configure and use kind of tool, so it's just easier to use than Achillies and others we've tried. Shows all the parameters from the client going out to the server, and raw text and XML, even compressed HTML coming back; opens up the client so it's not a black box any more.

Ethereal is also very popular.

While it's not a debugger, we've found the JavaScript Shell to be a really great tool for analyzing problems, and even just exploring JavaScript libraries like dojo. It works best as a Firefox bookmarklet, in which case you can open it in the context of any given page and invoke javascript functions yourself, evaluate expressions, redefine functions, etc.

Almost everything is rapidly evolving. There has been some major refactoring between 0.1 and 0.2 and again between 0.2.x and 0.3. This will continue apace until we're much closer to a 1.0 release. If you want to get a sense of how stable something is, one heuristic is to have a look at how many unit tests there are for it, and whether those tests pass.

Are unit tests always supposed to run error free, or is that only true for sections of the code that are fairly old and no longer rapidly evolving?

Unit tests should pass for things that the module maintainer considers to be "working". At any point in time, most unit tests should pass, but many may fail in modules that are still be actively developed. In these cases, module maintainers should be marking untested code using the dojo.experimental function. By running the unit tests and watching for "experimental" warnings you should be able to get some sense of which modules are rapidly evolving and which are fairly stable.