There are so many frameworks out there it is amazing. You can find many examples of MVC frameworks in action at todomvc.com. It was very difficult reading up on each framework, understanding them, and experimenting with them to see if they would work for us. Since we were already familiar with Dojo, we decide to start from there. We found a couple of articles and frameworks that others had already done. However, as usual documentation was lacking. What we did find was a very basic framework created by Christian Hoegl called Dojorama, dojorama.org and this served as our starting point. However it was built using version Dojo 1.9 the AMD version of Dojo.
Though we have been using Dojo for many years, we were using the non AMD version of Dojo and to us the new approach was like reading a foreign language. The structure of Dojo AMD and how it is used is totally different than previous versions of Dojo. You had to type so much more code in order to do the same thing. It seems ridiculous to us at that time. We struggled to make sense of what Christian was discussing. It seem to be too much work. So we drop Dojo as a possible approach.
We tried Backbone, but we had to rewrite many of our widgets that we already created in Dojo. In addition, we had to write more code to integrate with Backbone. Therefore, we dropped Backbone and went back to Dojo. So we spent many weeks learning and understanding the AMD approach used in newer versions of Dojo. Like always, most articles only presented simple examples. We were struggling to understand the newer approach since our mindset on how to approach a problem was totally different.
A Dojo widget does not need to be a combobox or a field, it is can be as simple or comprehensive as you want it to be. The class inheritance nature of Dojo widget makes it possible to extend the Dojo widget concept from being just a simple widget to a container widget or even something bigger and much more complex that inherits behavior from parent widgets. The critical part that Dojo provides is the ability to create classes, superclasses, and class inheritance without having to create your own structure. This is one of the biggest advantages that most developers using Dojo have never utilized. Unless one has created complex Dojo widgets, one probably would not be familiar with these features. The OOP nature of Dojo with classes forces you to follow structured design patterns which makes it much easier for others to follow and manage your development process.
This lifecycle methods define how a widget is created, initiated, and displayed. A Dojo widget can inherit the behavior and functionality from superclasses or from other widgets. In addition to these 7 lifecycle method for creating a widget you also have one method to destroy the widget.
For almost all cases the only one you normally would be using are:
Most of the time, if you are using a multiple page application, you would never need to call the destroy method since the widget will be destroyed as a you navigate between pages. For a single page application however, the destroy method is critical. What we learned as we will discuss later, the standard Dojo lifecycles was not sufficient for us and we had to create many of our own in order to make everything work the way we needed to.
Since we wanted iPhora Touch to be a multi-pane single page application, the structure need to be far more complex while being more robust. The HTML components within a Dojo widget page needed to be complex Dojo widgets and they themselves can be containers contain widgets. So we came up a layered Dojo widget based architecture that had the following structure.
Next time: Creating the Architecture - Dojo Widget Galore