Our Adventures into Creating a Secure MVC Framework - Part 3 - Experimentation

Now that we have defined our design requirements, we needed to determine the tools and approach that we would use to create our framework.

We had created previous versions of iPhora Touch using Dojo and wanted to start from scratch on what tools we would use to create our framework. Everyone that I talked to asked me why I was using Dojo since it is big and slow.  So we started looking at different options.  Do we take one of the existing more bare bones MVC framework like Backbone and take components from them to create our framework or do we start totally from scratch using JavaScript or jQuery.

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.

https://dojotoolkit.org/documentation/#tutorials

As a precursor to further our discussion, we need to talk about Dojo widgets. A Dojo widget is a collection of HTML template and JavaScript. One hot topic of discussion in the Web development in recent years has been the concept of web components.  However, in Dojo this concept is no more than just a Dojo widget. Therefore, the concept of view/controller, it is just a Dojo widget.

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.

When a Dojo widget starts up it goes through a series of lifecycle methods including:

• constructor
• postscript
• create
• postMixInProperties
• buildRendering
• postCreate
• startup

https://dojotoolkit.org/documentation/tutorials/1.10/understanding_widgetbase/index.html

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.

• destroy

For almost all cases the only one you normally would be using are:

• constructor
• postCreate

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.

With this body of knowledge and experience we went back to the Dojorama framework to see if you can utilize any of the concepts presented by Christian to create our framework. Christian treated a web page simply as a Dojo widget.  As one navigates between pages you were displaying a different widget. The Dojo widgets (pages) were containers with simple HTML element inside. He used Javascript within each container to controller the behavior of the elements within each view.  This immediately hit us that the use of Dojo widgets in creating our MVC framework was the right direction.

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.

Each layer was a Dojo widget starting from the core application layer all the way up to a widget like a combobox.

Next time:  Creating the Architecture - Dojo Widget Galore