[Dojo-interest] Large Dojo Application Design

Mattew Shirey mshirey at gmail.com
Fri Aug 29 19:07:54 UTC 2008

Thank you!  This is extremely helpful.  It sounds like you've been  
through much of where I'm heading!  I'll take a look at what you've  
referenced.  I cannot thank you enough and I'm sure I'm

On Aug 29, 2008, at 9:51 AM, John Locke wrote:

> 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
> problem.
> 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
> events.
> 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),  
> 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...
> Cheers,
> -- 
> John Locke
> "Open Source Solutions for Small Business Problems"
> published by Charles River Media, June 2004
> Follow me on Twitter: http://twitter.com/freelock
> http://www.freelock.com
> 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
> _______________________________________________
> FAQ: http://dojotoolkit.org/support/faq
> Book: http://dojotoolkit.org/docs/book
> Forums: http://dojotoolkit.org/forum
> Dojo-interest at dojotoolkit.org
> http://turtle.dojotoolkit.org/mailman/listinfo/dojo-interest

More information about the Dojo-interest mailing list