PureMVC in Dojo

Having moved on from Flex to Javascript more than a year ago, I’ve continually run into the problem of trying to find frameworks to support large-scale Javascript applications that are truly robust and scalable. It is harder than I thought, and that is at least partially due to the inherently fast-and-loose nature of Javascript. In the Flex world, Actionscript 3.0 was a dream for Java coders like myself that loved strongly typed languages with deep OO roots. Javascript is whatever you want it to be at any given moment: it can be as structured or chaotic as the author desires and still work. This is what makes it so malleable and useful while managing to make me insane at the same time.

Scalable systems however, require structure. Sure, you can build a scalable application using quick and dirty techniques, but you will be leaving out an overlooked and vital component: maintainability. If you are the only one who can figure out what the hell the code does, then what good is it? If no one can build upon the scaffolding you have provided, you can end up with a massive hotel with only one occupant.

There are a ton Javascript frameworks out there, but in the Flex world, my framework of choice was PureMVC. As far back as 2008-2009 PureMVC fans wanted to create an implementation using Javascript. Almost immediately they ran into the quandary of how to use it with their own libraries such as ExtJS, Prototype, Mootools, etc. Individual developer started porting it to their framework of choice, but this meant having multiple codebases to maintain instead of one. The decision was ultimately made to settle on a single native version that could used by everyone. At the time, I was working with what would eventually become Dojo 1.7, complete with AMD which was the “next big thing” to hit the Javascript world. I created my own port of PureMVC to work with Dojo 1.6 using AMD and I recently posted it here for anyone who needs it. In fact, I went one step further and created a Dojo version of the PureMVC Pipes utility as well. It is great to be able to load the PureMVC code on an as-needed basis with AMD.

However, Cliff is correct that in the long run, someone will have to keep that codebase in sync with any future PureMVC changes that come down the pipeline. So the best move is probably to utilize the native implementation of PureMVC and integrate it with the framework of your choosing. The issue then becomes: “How do I integrate it with ?”. Some developers have shown us the way for libraries like Prototype, ExtJS and others. However, there is not as much information on how to use PureMVC-JS native with Dojo, so I decided to post some examples on how to do it based on Cliff’s suggestions.

The first demo shows you how to create your implementation classes for Mediators, Proxies and Commands using PureMVCs “define style”, which means you use the puremvc.define function to create the OO structures that allows your MyMediator class to extend from Mediator in the PureMVC library. Only the main application and the view components are writing with Dojo. The argument for this way of integrating Dojo with PureMVC is that none of the PureMVC classes are reliant upon your framework and if you choose to switch from Dojo to something else, your PureMVC classes will required very few modifications. This makes sense, but I’m not sold on this entirely. First off, if you chance from Dojo to another framework, even if your PureMVC classes still work, the other 80% of your code will have to be changed. On top of that, while I like the clear and easy to use puremvc.define functionality, I would rather have all of my Dojo code look like Dojo code rather than have lots of code using puremvc.define while the rest uses Dojo’s define() function and style. Also, if you use the puremvc.define function, you have to make sure you load those classes up front and order them correctly. You get none of the beauty that AMD provides when it comes to loading what you need when you need it.

Run Demo 1

The second demo shows the same application but this time, the Mediators, Proxies and Commands are all built with Dojo and inherit from the classes defined in the PureMVC library. So I only have to load the puremvc.js file at the start of the application and my Mediators, Proxies, and Commands will all load when they are needed. Dojo will also include them in compressed layer file which is created by my build process prior to deployment so I get a clean seperation between the code I wrote and the code supplied by the PureMVC library.

Run Demo 2

The second method just feels better to me, but you decide for yourself: Here is a code-comparison of a controller class for each demo:

PureMVC define style:

puremvc.define({
        name: 'todomvc.controller.command.PrepModelCommand',
        parent: puremvc.SimpleCommand
    },

    // INSTANCE MEMBERS
    {
        /**
         * Register Proxies with the Model
         * @override
         */
        execute: function(notification) {
            this.facade.registerProxy(new todomvc.model.proxy.TodoProxy());
        }
    }
);

Dojo Style:

define(
    [
        "dojo/_base/declare",
        "todomvcdojo/model/proxy/TodoProxy"
    ],
    function(declare, TodoProxy) {

        var PrepModelCommand = declare("todomvc.controller.command.PrepModelCommand", puremvc.SimpleCommand, {
            /**
             * Register Proxies with the Model
             * @override
             */
            execute: function(notification) {
                this.facade.registerProxy(new TodoProxy());
            }
        });

        return PrepModelCommand;
    }
);

Both work fine but for now I’m sticking with the second approach. 🙂