Recently Justin Wilaby contribute to the PureMVC community by providing a new PureMVC port to JavaScript using Mootools. I expected a port to a better known JavaScript framework like Mootools since the first release of my port to JavaScript. My opinion is that we need a PureMVC port to each of the mainstream JavaScript frameworks. I'm still convinced that the more PureMVC code examples we will have for each of them, the more users will understand the gain in working with real architectures, even in JavaScript. That's why, on the announce of the PureMVC port to Mootools, I immediately engaged myself in porting the standard PureMVC EmployeeAdmin application from the Objs port to the Mootools one.

Working on the PureMVC JavaScript Mootools EmployeeAdmin Demo give me the occasion to better learn Mootools and explore what Justin Wilaby done with on his PureMVC port.

Structure

My first thoughts when opening the JavaScript Mootools sources was to compare it to the sources of the Objs port I made using a file compare tool.

Interfaces

The first evident difference I could see was that the Mootools port don't use interfaces as the interfaces package was missing from the folder tree.

Unit Tests

I also immediately looked for any Unit Tests folder as it was an important thing missing in the Objs port. But it seems that here, as with Objs, Mootools don't have any compatible Unit Test framework to test the port. Apparently Mootools developers use JSSpec, a test Framework to test their builds, but this is "only" a generic "Behavior Driven Development" framework.

Code

Differences are more subtle when looking at the pseudo-classes code.

Packages

Mootools doesn't provide any package support.

A project I work on recently had near 200 JavaScript classes, I must be honest, I found this could a real problem on such a project. But on small projects like the EmployeeAdmin demo, it's a real pleasure not to have to use package names and to directly use class names as reference to classes.

Constructors

This is a common implementation in prototyped languages and I assume it to be really convenient to use when working on the EmployeeAdmin demo.

Inheritance

The inheritance between two pseudo-classes is made by associating the super class reference to an Extends property in the subclass. This is a neat way to implement inheritance.

Importing classes

As you can see in the two examples above, there's no need to import classes in the context of the one which will use them, the class uses a direct reference to a class object instance instead. So, as each class object instance need to be built with the Class keyword, classes need to be declared following a strict order, e.g: Class B cannot use a reference to a Class A before this class has been built. This happens when using inheritance and constants referring to other classes simultaneously or simply when the initializer uses references to other classes. In some situation, this can lead to intractable problems where cross-references between classes require an order of declaration simply impossible to reach.

This said, some of this problems can easily be avoided by following good practices in code design. But whatever you do, even if you avoid the intractable situation, in big projects, it requires to change the classes declaration order so often that it can became a real problem.

In the other hand, the Mootools port and applications made with it are more clear that with Objs because you don't have the long import list at the start of each class.

Mootools prototyping

As many JavaScript frameworks, Mootools uses Native type prototype to add functionalities to Native types. Examples are the Array.contains, Array.indexOf, Number.toFloat methods. This is easier to use when programming, no doubt on this. But it sadly also write on the prototype of all Native types used in the current webpage domain context.

This first means that Mootools cannot coexists with most of the framework like Prototype, Jquery, etc... without some extra work. But it can also introduce unwanted problems in your own webpage with some existing code. That's what happened to me during the EmployeeAdmin development, I had to search during several hours the origin of a strange behavior on the User Profile form before understanding that the problem came from the Function.prototype.create method added by Mootools that override a create method in one of my own classes.

That's too bad, but it has for consequence that I simply can't use the PureMVC Mootools port on a project I already started a while ago because I can't add the code introduced by Mootools in the webpages of the project which are already containing many of different JavaScript components. Note that this is not a specific Mootools problem but a frequent problem with JavaScript frameworks.

Working on the EmployeeAdmin demo

Converting from Objs to Mootools

To build this EmployeeAdmin Mootools demo, I used the previous one from the Objs port and converted it progressively to Mootools. A great part of this work was easily made using Regular expressions and a good code editor.

The only problems I had are listed above. The biggest one was when Mootools inject one of its methods instead of one of my own classes with prototyping.

I used the example Justin Wilaby made for his port. It helped me not to be wrong with his port and Mootools. Plus he adds an interesting UIComponent class I reused.

Omnigrid Advanced DataGrid

The best evolution brought to EmployeeAdmin JavaScript demo by Mootools is the ability to use the Omnigrid Adavanced DataGrid for the users list. The design is clean, it has many functionality and can even be used to directly call results from a server by simply adding an url parameter to its initializer.

Upgrading to the EmployeeAdmin 1.4 version

Cliff Hall involuntarily made me a bad joke by upgrading the Flex EmployeeAdmin demo from 1.3 to 1.4 while I was working on it. So I had to upgrade mine just before releasing it today. The upgrade mainly adds a PrepViewCommand, a PrepModelCommand and change the Flex based design to the PureMVC graphic chart.

I agree that shifting to mootools means excluding some other frameworks and that’s bad. It’s against the grain of the PureMVC philosophy. The only problem is it’s either a potential explosion of PureMVC versions for different JS frameworks or PureMVC has to tackle the class simulation on its own, which is really outside the scope of it’s (designed) responsibility. So it’s a tough one to solve.

Matt Miller has posted a version of the PureMVC JS framework that doesn’t rely on any 3rd party framework for simulating classes. He says it should be compatible with mootools or any other framework.

I had a brief look, but I haven’t JavaScripted in a loooooong time; I wouldn’t be capable of evaluating it right now. I wonder if you might have a look at it and see if it does anything to bring us closer to JS harmony? I’d love to hear your thoughts, as you are a pretty solid authority on this. I don’t know anyone working with the volume of classes you do in a JS app.

It seems that there will be some interesting debate around PureMVC and JavaScript, excellent !

I’m already looking into the version of PureMVC that Matt Miler sent on the forums. My immediate reaction is that it seems a good idea. But I’m skeptic on the way we will have to inherit from PureMVC “abstract” classes with each framework as each framework use its own methods to achieve this.