Dojo and Firebug Tricks for Development November 10th, 2008 at 12:01 am by Tom Trenka
As an Ajax developer, I’m always looking for easy ways of helping my development process—things to make development faster, easier ways of checking things, etc. Today I’ll share two quick and easy tricks I use all the time when developing web applications using the Dojo Toolkit.
Trick #1: using window.location.search to enable Firebug Lite on the fly
With the Dojo Toolkit, I find this trick indispensable. The basic concept is to use the original version of the djConfig variable—the object-based one—using a boolean to enable or disable debugging.
In a single line of code, here’s the trick:
var djConfig = { isDebug: (window.location.search.indexOf("debug")>-1) };
What you are basically saying is “if you find the term ‘debug’ on the query string for the page, then enable debugging with Dojo”.
As an example of usage, say you have a page called “app.html”. To enable the Firebug Lite console (in a browser other than Firefox, of course), all you need to do is reload the page with the following URL:
http://your.local.site/app.html?debug
…and you are off to the races!
Trick #2: setting up a simple HTML file that just enables the console
This one is probably my all-time favorite—because not only does it take advantage of the Firebug console, but it also takes advantage of Dojo’s package loading system (a.k.a. dojo.require).
I create a simple HTML file, console.html, and drop it into the root of a Dojo Toolkit checkout (i.e. a sibling to /dojo, /dijit, /dojox, etc.). Here’s the entire file:
<html> <head> <title>Dojo Console Testing</title> <script type="text/javascript" src="dojo/dojo.js" djConfig="isDebug: true"> </script> </head> <body> <p> This is a quick and dirty file you can use to do console-based development. </p> </body> </html>
…that’s it. That’s all there is to it. All it does is load up the Dojo Base (i.e. dojo.js) and enable the Firebug console—and that’s really all you need.
Ok, so how do I use it?
I’m glad you asked… so here’s the beauty of this simple HTML file. When you load it up, open Firebug and enable the Run area:
Now let’s take advantage of the Dojo Toolkit’s package system. Say we have a simple XML file we want to load and make sure we parse correctly. Type this into the Run area of Firebug:
dojo.require("dojox.xml.DomParser"); var xml='<?xml version="1.0"?>' + '<root><node>My first node</node>' + '<node>My second node</node>' + '</root>'; var doc=dojox.xml.DomParser.parse(xml); console.log(doc);
…like so:
From there, hit Run:
…and then you can inspect the results using Firebug’s Object inspector tools:
Pretty neat, huh?
So what we’re basically doing is using the dojo.require method to load up a Dojo Toolkit module (in this case, the dojox.xml.DomParser) and run some code against it. Since dojo.require always runs on-the-fly (i.e. you don’t have to pre-load modules while a page is loading, and you can even load a module long past the onload event), you can load whatever you need as you need it.
This trick works with all of the Dojo Toolkit as well—you’re not limited to non-UI based code. Loading and popping Dijits into a document to test things out will work just as well (though you might want to create a <div> container to isolate that from the rest of the document).
Conclusion
Every developer has their own tips and tricks they use to make their life easier; I hope these two tricks will make your own processes much more efficient!
Posted November 11th, 2008 at 4:25 am
[…] Trenka has a nice posting on Dojo and Firebug Tricks for Development where he shares two of his […]
Posted November 12th, 2008 at 1:40 pm
Awesome! I hadn’t thought of #2… great idea.
Posted November 15th, 2008 at 5:01 pm
I like #1. I tried baking it into a custom build using the flag:
scopeDjConfig={isDebug:(window.location.search.indexOf(”debug”)>-1)}
But the build command seems to choke on the parentheses. My workaround was to add this to my dojo.js file after the build has completed. Any ideas how I might make this work? Or conversely why I wouldn’t want to use your trick in a build?
Thanks for the tip!
Posted November 19th, 2008 at 10:10 am
@Morgan:
I don’t think I’d want to include that in an actual build, especially given that it’s one line of code–in general, I pull that line when an app is deployed (last thing I want is for someone to be kicking in debug mode to formulate an attack on the app itself).
I find it’s simple enough to just include that in the beginning of your documents.