MooTools PureMVC Port

[Justin]

Thank you for the accolades! 

A lot of that syntax is there to maintain auto-complete and code hinting in NetBeans as well as make the comments fully readable by JSDoc. 

Pesky maybe, but necessary.  Those functions exist merely to create the Object that provides a map to the MooTools Class object.  if I had <code>function sortZ()</code> as you suggest, the constructor would fail to create a property on the new object called sortZ.  I would have to reference the prototype each time which essentially accomplishes the same thing (but with more typing).

I can't wait to see some of the projects this port is used in!

Cheers!

Justin

[puremvc]

OK, folks, here's the news.

I'll be posting in more detail on the front page soon, but basically the decision was to deprecate the Objs-based port in favor of the MooTools port.

The old port was never documented and was based on the Objs utility for class relationships. Consequently, the implementation code was hard to understand and the Objs dependency was too intrusive and cumbersome. This was a big barrier to its adoption.

This new MooTools-based version is fully documented, and the framework code and resulting implementation code (the BoxSplash Demo) is extremely clean and understandable. And MooTools has a broad user community. If we must rely upon another framework, then MooTools is a better target. There simply is no reason to confuse new users with two options for the Standard framework version.

Also, the single file JS include of the framework is 44k, but I've included an 8k minified version (using yuicompressor with -nomunge) and the demo runs properly with both.

In the repository, the Objs port remains on a branch, and the old EmployeeAdmin demo remains available (see the release notes for the port).

The current version of the framework is now 2.0 and you'll see all the rest at http://trac.puremvc.org/PureMVC_JS

Cheers,
-=Cliff>

UPDATE: Ok, I've updated the Darkstar Roamer's XML map to include the new port and demo, and have posted to the front page of the site.

[Tekool]

I had a quick look on the port. Usage of mootools seems a good choice for a PureMVC app. I will have a deeper look into it when I have time.

Cliff, it's a bit unfortunate that we do not maintain more than one JS Framework for the port. Mootools is one solution, many other will prefer others which will not be compatible with this one.

I agree on the flaws of Objs. It has been written in few days only. I had to make some choices, mine where to use *Object.prototype* all the way and to have something to work with my team, so I needed something made specifically to work on multiple files. I always been agree with Cliff that we need a port on another framework that Objs. Mine may help on this.

Some questions now

Which tool do you use to create the monolithic file from your multiple classes? And does Mootols support a system of Interface implementation ? I saw a reference to an "implement" method but is it the one used to check if all methods of a class where correctly implemented regarding a "pseudo-interface" ?

[Tekool]

Note that I will port my Objs EmployeeAdmin demo in the Mootools port. First release will be as is. Only a conversion from one port to the other. It will be pretty easy. But I will try later to add a support for JQuery above to add some beautiful components.

Hope this helps.

[puremvc]

Cliff, it's a bit unfortunate that we do not maintain more than one JS Framework for the port. Mootools is one solution, many other will prefer others which will not be compatible with this one.

I did put the old port on a branch, and there it can be maintained and bugfixed.

It is not a decision that I made lightly, and I hate it that there has to be a dependency on any outside framework. PureMVC is meant to be tied to language not platform. This is why I long contended that a port to JS was not possible.

As you say, some will be ok with MooTools, but others will want some other framework or approach for doing 'classes'. If we go down that avenue then we might end up with 10 different PureMVC Standard for JS ports. Each with its own ports of various utilities. That way lies madness. Not only from a maintenance standpoint but also on the part of the new developer who comes to the site and tries to figure out which port to use.

And does Mootols support a system of Interface implementation ? I saw a reference to an "implement" method but is it the one used to check if all methods of a class where correctly implemented regarding a "pseudo-interface" ?

IMHO, JS developers aren't likely to care about interfaces (or they'd be using Java or AS3 or some actual OOP language). So in the end it comes down to easily accessible docs, and the simplicity of the developer's day to day implementation code.

Note that I will port my Objs EmployeeAdmin demo in the Mootools port. First release will be as is. Only a conversion from one port to the other. It will be pretty easy. But I will try later to add a support for JQuery above to add some beautiful components.

This would be super! Just the straight port will help to get AS3 people over since they'll have the AS3 reference demo.

And after having a look, I believe that this can work with JQuery. I may be fatally wrong, but I'm not seeing anything at the moment that prevents it. Here's a very brief article about it.

http://davidwalsh.name/jquery-mootools

It's funny reading the comments on that article, which simply shows how to set some text color with JQuery and border color with MooTools. Looks simple enough but the thread breaks down to an argument over whether one should use multiple frameworks in a page or not with the main detractor saying that if you want to use a JQuery component on a MooTools page you should port the component (and visa versa). That seems completely daft to me. I'd really like to see if the new port works with JQuery as well.

-=Cliff>

[hamannp]

Do you guys have a roadmap for this port?  More specifically, is there a multi-core version planned?  I'm using MooTools on a current project.  I'd like to evaluate using this port.

RE: the desire for OO class structures without using a major framework: may be this? http://jsclass.jcoglan.com/

Thanks! Paul

[Tekool]

A multicore version wouldn't require so many changes compared to the current one.

But as there's currently no support for packages in the Mootools port, it requires that the user understand some best practices first. Each core will have to be protected by a function body to avoid any collision between StartupCommand, PrepModelCommand, ApplicationFacade, etc... classes names. A demo and a how to will be necessary. So, finally the demo and documentation will be the largest piece of work to achieve.

JS.Class seems highly interesting. Is it mainstream now? It's the first one I saw which was mainly focused in reproducing a real Object Oriented programming paradigm with JavaScript. It is not so different in syntax from Mootools. It wouldn't take to long to create a port to it either.

[hamannp]

Thanks for your response.  To net it out for my simple mind: The multicore version is manageable in scope, but has to be done with a little bit of care.  Yes?

Both JS.class and Ojay [ written with JS.class http://ojay.othermedia.org/ ] have gotten some good press.  There is also a copy of gruff called bluff [ http://bluff.jcoglan.com/ ].  So, I would say that it clearly can handle at least medium-sized apps with elegance.  I've used Ojay quite a bit and Bluff. I think that those two apps speak highly of the underlying concept of JS.class.  Best of all,  the author continues to maintain JS.class.  It's also exceptionally well documented.

Overall, it's difficult for me to measure "main-streamness".  I would say that most would agree that Ruby has at least some good OO concepts. There's certainly a large community that would be able to cross-over easily.

Cheers! Paul

[Tekool]

The multicore version is manageable in scope, but has to be done with a little bit of care.  Yes?

Yes, I don't have time look deeper into it now, but in my opinion it will requires to encapsulate each core code by a function body like that (it will look like the modules in JS.Class and Ruby so) :

Code:

function FirstCore()
{
    //All the code required for the first module here
}
FirstCore();

function SecondCore()
{
    //All the code required for the second module here
}
SecondCore();

Quite simple so, but it's mandatory to run a multicore version of this port.