|
 One of the things about PureMVC that makes it so portable is the fact that it doesn't rely upon any other frameworks or libraries.
The PureMVC Way eschews platform dependency and all but the simplest language constructs in doing what it does. As a result, we've found that its classes, responsibilities, and collaboration patterns can be expressed in nearly any OOP language. So, for quite awhile, I held that we could never have a 'proper' port of PureMVC for JavaScript, since it doesn't offer Classes, Interfaces, and Inheritance in the way that OOP languages like Java, C#, or ActionScript do. Dependent Ports Emerge Then there came a flurry of ports - first for MooTools, then Objs, then Sencha ExtJS, then Prototype. While these ports proved PureMVC could be ported to JavaScript, they still had a fundamental break from the Way: they relied upon those other frameworks to do the class simulation. So, if you were writing an app using MooTools, you could get your PureMVC on, but you had a problem if you ever wanted to switch your view components over to ExtJS, for instance. So, in the case of JavaScript, we accepted a compromise in the PureMVC Way. We maintained multiple branches of the framework, one for each supported UI or OOP kit. Things went OK for a bit, but then the inevitable happened: Sencha released ExtJS 4 and the PureMVC ExtJS port and demos were rendered immediately useless. And not just for need of swapping the Sencha library. That branch was really broken. Native Ports EmergeSerendipitously, around that time, there had been not one, not two, but three Native JavasScript ports submitted. The ports - submitted by Alain Duchesneau, David Foley, and Frederic Saunier - were all fully functional and quite similar in implementation, but they varied just enough that we decided to reconcile all three, using the best possible method of each faux-class. A long series of debates on the finer points commenced, and David Foley was tasked with the job of producing and sheparding the final port. This included documentation, unit testing, and demoing. Meanwhile, PureMVC ExtJS port owner Tony DeFusco looked into why the port had gone belly up. Apparently, Sencha made backward-incompatible changes in the way it handled class simulation. This meant if we were to keep up with Sencha, we would need to release and maintain ports and demos for ExtJS 3 and 4. That way lies madness. Instead of creating another dependent port on a different version of a different popular UI library, and setting further precedent for dependency on external frameworks, Tony took an early release of the newly reconciled PureMVC MultiCore Native JavaScript port. He made ExtJS 3 and 4 versions of the BoxSplash and EmployeeAdmin demos that work with the Native port. We decided NOT to release a ExtJS 4 dependent PureMVC port and further, to deprecate use of the ExtJS 3 dependent port. Third-party Class Simulation with the Native Port Now the thing that the Dependent Ports had a plan for that the Native Port didn't was how to do classes. The Native Port uses pure JavaScript and provides inheritance by properly manipulating the 'inheriting' object's prototype. It does this in a straightforward, albeit slightly cumbersome way, owing to JavaScript's fundamental design. The next step after creating the port and unit testing it, is understanding the idioms the developer will use to adapt PureMVC to his or her project. If you are used to writing classes in MooTools syntax, you can use the Native Port and still write your classes in the MooTools Way. That's what Tony did with the updated ExtJS 4 demos. Native port, Sencha style. No problem. However, if you decide to write your own classes in the style of the chosen UI framework, you're unnecessarily coupling yourself to that framework. If you start with MooTools and later want to use Sencha components, you may then find yourself having to rewrite your entire application based on a change at the View. Not a good choice, but certainly one that you are free to make. The alternative, was to use some clunky JavaScript idioms in every class you wrote to deal with inheriting functionality from the PureMVC framework classes. While it would work, you'd really have to be in love with the purist approach to put yourself through the hassle. Welcome to PureMVC Native Namespace and Class Simulation By deciding to add an optional bit of functionality to PureMVC, we bent another rule in the PureMVC Way; expanding the scope of the framework. But it was worth it and compared to the Dependent Port apporach, a smidgen of scope creep was by far the lesser of two evils. There are two bare methods available on the PureMVC Native port: puremvc.declare() and puremvc.define(). These allow you to add an arbitrary object to a given namespace, or to define a class with namespace, parent for inheritance, instance members, and class members. As a result, you can use PureMVC idioms to create all your 'classes' and employ any combination of UI or Ajax kits to communicate with the user, the browser, and the cloud. This is the most portable way to write your application. PureMVC is a central organizing principle - nearly all your code is based upon its patterns and framework classes. In return you get portable code with proven patterns that let you solve pretty much any problem with ease and scale the application up massively while remaining portable and maintainable. But if you find yourself writing code to communicate with the server, and the style of that code is governed by a library intended to provide primarily UI components, you have to ask yourself why you'd build such a dependency into your code if you had an alternative. And so, the Dependent Ports are still available, but the Native Port and its namespace and class simulation are the recommended way to build your application. David provided new Reverse Text demo that uses the native port. I made several changes to it and what is released demonstrates basically all the usual actors and communication patterns that are the building blocks of every PureMVC application. It is a simple demo, but the principles behind it are proven to scale to meet the demand of the enterprise and everything in between. Regardless of the what you think about the suitability of the browser for deploying enterprise apps, you will need a sound methodology to succeed. After working with the Native Port, I'm happy to say I enjoyed working with it and look forward to using it myself in situations where JavaScript is the appropriate choice. Cheers, -=Cliff> |
