[Dojo-interest] A Very Basic Widget Controller and Factory using only Dojo
j105.rob at gmail.com
Wed Jun 30 09:22:01 EDT 2010
weight client in years. My background is more server side, high performance
computing (scientific modeling apps), so please cut me a little slack if I
have made any gross mistakes!! Any help or insight is appreciated. All
comments are welcome.
I am currently contracted out to a client who started down the Dojo route
before I got here. I have been working with Dojo 8 hours a day for the
past 4 months. I am the only development resource working on an app (team
will be expanding this month) that now has over 100 widgets utilizing pretty
much everyhting Dojo Toolkit has to offer. The application is backed by PHP
and MySQL on the sever side; Client side is all Dojo in a single page. The
entire project (iKarma) is available as Open Source on software.Forge.mil;
if you have the proper credentials (CAC or ECA) come help me out with
I have attached 2 files in a zip to provide an example of how I attempted
to create a widget factory and controller on the client side using only
Dojo. This code is really a demonstration, not meant to be complete nor
I am providing it now, since Scott requested it yesterday in his post about
performance. It helped me reduce my load time by 2/3 and I have not even
done a build yet!!
Here was my initial task:
Develop a frame work using only Dojo to provide a Web 2.0 front end and
allow people to customize the UI by adding plugins (Dojo Widgets) to the
Improve application load time and to have the widgets load(activate) and
unload(deactivate) themselves, as the prototype was really slow since all
widgets loaded without regard to timing of need.
Ensure that the application was extensible, as the requirements change
frequently and additional components are added almost daily.
My problem was that there seemed to be no widely available solution using
Dojo. Not sure why, as I would have assumed that this problem would have to
be solved by anyone who was creating an all Dojo app. So I fell back on my
server side knowledge and started trying to figure out what type of pattern
would help me overcome these issues. I settled on a MVC/Factory pattern. So
I started looking around the web to see if there was anything implemented
using Dojo. There is very little out there, or my Google skills need
improvement. After a week of looking, I gave up and started looking into how
Dojo would want me to do it (based on how the toolkit is put together). I
knew what I needed to do, so I started reading the source code. That is
where I found the little nuggets I needed to solve this problem. Pulling the
covers off of Dojo and reading the code has taught me a lot about how to do
things with Dojo.
Here is the basic concept:
1. A controller is created in the addOnLoad(); it is called
2. This controller subscribes to 2 channels for getting notified that it
needs to either activate or deactivate a widget
3. It also defines a cache of objects (karma.Cache) to allow widgets to
share items; such as common stores.
4. This controller also creates an instance of the top level container for
the widgets to be placed in (in this case karma.container.Main); eventually
this will be refactored out of this class to improve encapsulation
5. Inside the karma.container.Main widget (which nothing more than a border
container), messages are published to the controller to tell it what widgets
to activate and where to place them.
6. When the controller gets the notification, it goes thru a 3 step process
to create an instance of the widget requested.
a. It looks to see if the widget is already activated by looking at the
b. If it has not yet been activated it then creates an instance of the
widget. It also does the require for the widget and sends in any parameters
to the constructor.
c. It then places the widget into the dom (or not). If the widget requests
the target container to be cleared before placing the widget into the dom,
it handles removing all of the container's children
d. It also knows if the target allows children to be added, and if not it
appends to the target dom vs. adding as a child.
7. If a request comes in for a widget that has already been activated, then
the widget instance is pulled from the widget registry and placed into the
target container. This allows you to create an instance of a widget for
later placement, should the need arise. I use this concept when I have
containers that I switch in an out of the visible dom.
This controller assumes some things:
1. Your namespace is only 2 levels (e.g. karma.level1.widget)
2. You only need to have 1 instance of a widget activated at a time; I might
change this later.
3. Templated widgets ( _Templated) inherit from an extended _Templated which
provides a bool to notify the controller that it is a descendant of
_Templated; this will be changed later to look at the inheritance chain of
the widget directly.
Hope this helps!
-------------- next part --------------
An HTML attachment was scrubbed...
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 298 bytes
Desc: not available
Url : http://mail.dojotoolkit.org/pipermail/dojo-interest/attachments/20100630/79d420ad/attachment.zip
More information about the Dojo-interest