PureMVC JavaScript Mootools EmployeeAdmin Demo

Mootools and PureMVC logos

As you may know I'm the author of the first PureMVC JavaScript port. I started it in 2008 using a little library of mine called Objs. I also provided a JavaScript EmployeeAdmin demo to test it.

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.

Screen capture of the application

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.


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.


Folder tree comparison between Mootools port and Objs one

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.


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


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.


Another difference is that Mootools pseudo-classes use an initializer method instead of the legitimate constructor, as explained on this example extracted from the mootools help website :

Mootools initializer implementation

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


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.

Mootools inheritance implementation

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.

Live demo, sources

10 Replies to “PureMVC JavaScript Mootools EmployeeAdmin Demo”

  1. Great work, Frédéric! This really looks slick. I like that datagrid.

    Sorry for making a bunch of changes to the reference just when I did, but I guess at least that keeps you from needing to revisit this. 🙂

    Thanks for pointing out the differences (and potential gotchas) introduced by mootools and for leading the way on this.


  2. Thank you for this encouraging comment, Cliff

    The update from EmployeeAdmin 1.3 to 1.4 took me at least 2 hours. So this was only a funny anecdote. 😉

    I like the new design too.

    I only realized that I had forgotten to add the User Profile validation. I will try to add something that looks slick too for it during the week.

  3. 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.

    On that note, I was just sweeping through the forums and came on this new post:

    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.


  4. 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.

  5. I have updated PureMVC JavaScript Mootools EmployeeAdmin Demo to v1.1.1.

    I have added user form validation, fixed some bugs and changed the CSS to use only relative positions.

  6. Pingback: Tekool.net — Développeur Flash — PureMVC JavaScript Mootools … | RefreshTheNet

  7. Thanks Tcab for this important information. I will try to have a look into this. I don’t own an IPhone, it will not be easy. 😉

  8. From my test, I realized that IPhone do not support multi-selection list and seems to have problem with the onchange event of the simple select list of the role combo.

    The solution would be to add a single column datagrid instead of the multi-selection list of the role panel. I’m skeptic on what happens on the second problem.

    I will wait for some tests on IPhone OS4, those behaviors probably have changed ?!

  9. Tested under Android, it works but the layout suffer the same problem on User Roles list than with IPhone OS. I will use the Omnigrid Datagrid instead asap.

Leave a Reply

Your email address will not be published.

* Please Add the Values