[Dojo-interest] Large Dojo Application Design

John Locke mail at freelock.com
Fri Aug 29 16:51:36 UTC 2008

Hi, Matthew,

I'm in the midst of a large project facing similar design issues as
yours, and I think we've come up with solutions to large parts of the

The code is a mess, since I don't have that much time to work on it, and
I've switched toolkits a few times since the beginning... but it is in a
public SVN repository here: https://baker.freelock.com/svn/auriga ;
there's a demo at http://demo.freelock.com (follow the Project Auriga
link). There's also more documentation at http://projectauriga.org.

I have switched to git for repository management, and being able to
manage dojo builds in source control is one of the key reasons. I
haven't published a git repo yet, because I accidentally committed a
password I use on dozens of machines, and git is VERY good at not
forgetting anything ;-) We're also going to be rebuilding that demo
server soon. So the codebase in SVN is a couple months behind our
current development, though we are using the head of that trunk in
production right now. (if you want to include Dojo in your git project,
do this: "git submodule add git://git.freelock.com/git/dojo.git 
path/to/local/dojo" to get a full copy of the Dojo repsitory).

There are several parts to the issue, and our design has been a very
iterative process. I'll add new features using the best practices we've
learned from earlier parts, so the best interfaces are sort of the
fringe ones--the billing and payroll screens.

This is pretty much a single screen application (with a few different
screens for external users). When you're one of the primary users, you
get a screen with a tabbed interface. We've got a 3 column layout, with
some always-needed widgets in the left column, the main tabbed interface
and a toolbar in the middle, and a help pane/toolbox pane on the right
which is closed by default.

I have a controller that manages opening new tabs, as well as handling
the back button events. Users can open and close tabs as desired, and
use the browser back button to go backwards, re-opening a closed tab if
necessary. New tabs are content panes that load HTML from the server.
That's the central part of the application. It also maintains context
for the help pane, so that when you switch tabs, if the help pane is
open it loads new documentation.

Another crucial part that isn't fully developed in our app but works
really well, is the topic system. We're defining topics to publish
events to, and this provides quite effectively the loose connections
between modules we need. Any tab can subscribe to any topic. The module
that's publishing the event doesn't need to care--it just publishes its

Each tab has its own support script, grouped into a module. We use the
dojo.require functionality to load it on demand (working on the new
layered builds offered by 1.2). We make extensive use of our own
widgets, often extending native dijits or dojox widgets, sometimes
completely from scratch.

Within a tab, our users have decided they like having two columns:
usually a tree widget in the left to be able to drill down to specific
items, and item details that load in the right pane. (you'll see lots of
other layouts in our demo, but that's the one we're using going forward).

On the server side, we have a pretty simple dispatcher that loads a
module specific controller, and calls its dispatcher method providing it
with a response object. That response object can be HTML (Smarty), JSON,
or XML (DOM), and it's specified by a GET parameter. The controller
simply does what it needs to do with the request, and loads the response
object up with the appropriate data. This is really great for
troubleshooting--you can change the view to XML to be able to quickly
see what you're getting back from the server, even when the application
is really using JSON. Avoids that pesky "Save" dialog...

I hope this gives you some ideas, and if you have any questions, I'd be
happy to share what we've learned in this process...


John Locke
"Open Source Solutions for Small Business Problems"
published by Charles River Media, June 2004
Follow me on Twitter: http://twitter.com/freelock

Mattew Shirey wrote:
> Thank you for your post.  Though I think it misses the point of the  
> question I'm trying to ask.  I'm already experienced with using dojo.   
> Though I would not call myself another more than a novice.  I started  
> with 0.4 and have ridden the exciting development path to 1.1.  I'm  
> quite familiar with everything you've outlined here.
> I'm looking for something more advanced.  I'm looking for a well  
> organized way to use dojo in a very large application with multiple  
> developers.  Based on the responses I'm getting, I guess I may be on  
> my own on this one.  At this point since I know the author of  
> "Mastering Dojo" knows what I'm looking for I guess I should attempt  
> to contact him.  At the very least he might be able to help me better  
> phrase my questions.  I do apologize that I cannot seem to do better.
> -- Matthew

More information about the Dojo-interest mailing list