creative developer

Hi I’m Ben:

I like to call myself a Creative Developer. To me, Creative Dev means working on the intersection of web, mobile, applications, and art. It means that I can do full-stack development to get a project done, but also favor the user interface and would prefer that the UI represents the immersive experience and the artistic edges of application development.

i can be found working on

The long and short of a simple UI Component in Dojo

Understanding Dojo is sorta like understanding Star Wars…you need the entire backstory to be able to figure out what’s going on.

On the surface, using Dojo elements are as simple as using HTML. You sprinkle a little bit of Dojo-ness in the div tag and it works. Pretty straightforward!

On the same token, Star Wars seems like a pretty simple story of good guy fighting the bad guy to get the girl. It’s only when you get the backstory, you understand why Luke and Leia kissing is kinda gross, and why Vader doesn’t want to outright murder Luke.

With Dojo, it’s the same deal – if you don’t understand the backstory, you’re only going to get things working by sheer dumb luck.

Say I Google how to do a simple progress bar in Dojo. My first hit is this page. I even have code I can copy and paste that looks like HTML!

First of all, I might be thrown off by Googling “dojo progress bar” and coming up with dijit.ProgressBar. That’s lesson the first!

Dojo is divided up into 3 separate projects: Dojo, Dijit, and Dojox. Dojo is the center of it all. In it’s (almost) 90kb core, it offers a lot of the same stuff something like jQuery would offer. The rest of the Dojo namespace has extra things which we can pull in as we need them (more on this in a bit).

Dijits, or “Dojo Widgets”, are the UI components to the Dojo team. ProgressBar, being a UI component, lives here in this namespace.

Dojox features are the more experimental features. What’s here might not be central to the Dojo vision, but pretty close – close enough to be shipped with the rest of Dojo.

What you should understand, is that all of these features put together weigh in at 5.3MB when you grab the zip. You might say that’s too large to include in your project. You’d be right.

Fortunately you don’t have to force this on your users all at once (nor should you). The 90kb Dojo core is all you need at the start, but as you need the other features of Dojo, you can pull them in realtime.

In other languages this might be an “include” or “import”. In Dojo, it’s a “require”. So now the next piece of this puzzle, is to require the progress bar:

If we were simply using Dojo programmatically, this is all we’d need for basic functionality of a component…but we aren’t! We’re using some nifty declarative HTML markup, so there’s one last step. We need to tell Dojo to scan the tags on the page and look for Dijit components. We do this by altering our script tag to be:

Unfortunately, while our progress bar exists, and it technically works, it’s looking kinda silly. That’s because we haven’t bothered to load our themes in yet. Without a theme picked, we get a barebones component which kind of looks like a broken wireframe.

At this point, I’m going to go to my handy Dojo Theme Tester and pick the Dojo theme that suits me best for the immediate future. Claro looks good, so I’ll use that. Not only do I need to include the Claro CSS and the Document CSS, but I also need to assign my body tag with a Claro class so that my entire document uses this theme.

Now we’re rocking! We have a Dijit Progress bar functioning on our webpage. Even though the point of this post is to simply get a UI component onto the page, I really can’t leave it hanging at 0%. Let’s go ahead and crank it to 80%.

For this, we’ll need a bit of script. For the sake of ease, I’m going to ignore all good sense and just put it in action in my HTML script tag.

We’re going to change our Javascript slightly – instead of a simple “require” directive, we’re going to have it do something after the required thing has loaded.

There are a couple of cool variations to this require script. First of all, you’ll notice that we’re requiring an array of Dojo components. Typically, we’ll just want to listen for “dojo/ready” and perhaps a custom script and start our application from there.

Secondly, you’ll notice that we didn’t pass in any parameters through our function. Each index in our require list corresponds to each function parameter. So I could do the following:

require(["dijit/ProgressBar"], function(ProgressBar) {

See, when you require something, the parameter that comes through in the function is the constructor for that component. We can instantiate this object from this parameter!

However, what we REALLY want to do is tweak the progress bar we already have. So we need to find the existing progress bar on the page. You’ll see two references in the Dojo docs to “byID”. One is dijit.byId, the other is dojo.byId. The rule of thumb here is that if you want a reference to the DOM element, you would use dojo.byId, and if you want a component reference use dijit.byId.

Unfortunately, this is allllll old news in Dojo 1.7! It’s very confusing – but this way of selection is in lots of basic documentation! Now, we use the “dom” object to find something in the DOM, and the “registry” object to find something in Dojo’s component registry.

We’re going to need to step up our game here, and require the “dom”, the “ProgressBar”, and the “ready” component. In this way, it’s kind of a lot to ask and checklist for basic setup, however once you get rolling, I PROMISE it gets easier.

Here, we require all these necessary components. We then hinge the usage of our script on when dojo is “ready” and has loaded all that we required. We get a reference to the HTML declared component through the registry. From there we can update the progress bar as we want!

It’s unfortunate we had to go through such a long journey and learn so much to get to such a basic state – and that, I think, is Dojo’s biggest weakness. If you choose to power through this initial learning and setup phase I really think you’ll find Dojo to be absolutely fantastic.

There will be the moments when you bang your head on the desk because you missed something really stupid or the Dojo docs weren’t clear enough, however once you get into the rhythm of writing the code, it’s a fun and productive toolkit to work with.

I spent weeks/months on this? Um no. I spent the better part of a weekend learning the basics of Dojo and fleshed out an application at the same time. I spent several nights over the following 2 weeks figuring out the Dojo build system which is fairly more complex, but not required.

I am fairly critical of the lack of great documentation in Dojo, which makes doing something like this take a few hours instead of the 5 minutes it should take. That’s why I wrote the post – to save people some time, and hopefully make the initial learning curve a little less steep.

But weeks and or months? God no. And I didn’t learn nothing….I learned a pretty decent tool.

In terms of large enterprise frameworks – I started learning this at the same time as some other folks were learning Sencha/ExtJS, and I heard some similar frustrations in my twitter stream coming from that end. As in, both Dojo, ExtJS, and probably other enterprise level frameworks might be a little more frustrating than they should be, but it comes with the territory. Flex takes some time getting up to speed too. jQuery is significantly easier, but as you start getting into larger applications people seem to bring more complexity like Angular, Backbone, etc. All good stuff, but does have a learning curve.

Not sure which tech you’re coming from here, but Dojo is pretty solid to me and seems on par with other similar tools.

I also checked with some other folks who have been using Dojo for much longer than I have (for some better perspective than my short time with it), and they still dig it.