Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought

Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Author Topic: Stand alone version?  (Read 9268 times)
Posts: 1

View Profile Email
« on: March 10, 2010, 10:42:29 »

I don't think it is necessary to tie the PureMVC JavaScript port to any third party library like Obj or MooTools. The prototype linking for simulating OO is not too difficult, and once implemented can allow the JavaScript port to be used with any 3rd party JS library that implements an OO simulation scheme for creating subclasses of the PureMVC classes.

Many websites that can benefit from the JS PureMVC port already have committed to one library or another. This means that the decision to use PureMVC or not will often come down to the question of whether or not the site has to include yet another 3rd party library on the site in addition to PureMVC and what they already use.

I've attached a version of the port that has no external dependencies. I have not tested it much, but you can see that removing the dependency is not complicated. It will also not prevent using the PureMVC "classes" with 3rd party libraries for creating subclasses.

If I didn't make any mistakes in the attached file, you should be able to drop it into any web app already using either the Obj or MooTools JS PureMVC (replacing the current PureMVC file), and it should work with no other modifications. The difference being that the same file can now also be used in other web apps without the Obj or MooTools dependency.

Matt Miller
Global Moderator
Hero Member
Posts: 2871

View Profile WWW Email
« Reply #1 on: March 15, 2010, 09:56:50 »

Hi Matt,

I've requested that Frederic Saunier have a look at this if possible. He just released a port of the EmployeeAdmin demo1 to the new mootools port, and as the author of the previous port, he's probably the best authority on how well this code would solve our problem. Essentially we're looking at an explosion of ports to fit different JS frameworks, OR handling the class simulation internally which lies outside the intended scope of PureMVC.

But then if it's done right and will allow a universal standard that will work with all the other frameworks AND not be terribly annoying to developers who have to instantiate PureMVC classes one way but mootools or jQuery classes another...

It's clearly where we want to go, I think. But Frederic will be able to speak more to the implications that arise in large scale projects.

1 http://www.tekool.net/blog/2010/03/14/puremvc-javascript-mootools-employeeadmin-demo/
Sr. Member
Posts: 192

View Profile WWW Email
« Reply #2 on: March 15, 2010, 02:42:29 »


a PureMVC JavaScript base without any dependencies at all, ready to be "embedded" in any framework is a good idea. But I'm not sure that it will technically be possible without adding too much extra code and complexity.

With the PureMVC Mootools port in mind and the example you post, it would probably be easy as Mootools can "decorate" any JavaScript pseudo-class with its own methods. We will just have to write something like :
Mediator = new Class(new org.puremvc.js.patterns.mediator.Mediator());

I not have verified, but as Mootools use prototyping for inheritance, it will probably respect inheritance from Mediator to Notifier. When "decorating" the singletons classes we will only need to rewrite the getInstance static method, etc...

Finally each framework will require specific extra code to embed PureMVC. This is as extra steps needed before a beginner understands how to use PureMVC in his project with his preferred framework. Also, I thought that an advantage of this solution would be that it only requires one source to be updated for all framework when PureMVC changes. But finally, we would probably have to change the code to embed PureMVC in each framework too. That's why I'm not sure this is the better idea to spread PureMVC in all frameworks.

That being said, this is only hypotheses, it should be tested to see how much code it needs to add to a project in each framework to have a real Proof Of Concept of this idea.


In large scale project, the only difference would be that each Class of the PureMVC framework would have an inheritance extra level. This could add some more CPU steps on each method call, but I'm not sure if this will really be noticeable.
« Last Edit: March 16, 2010, 02:56:11 by Tek » Logged
Pages: [1]