I mentioned having thoughts about this, and I'd like to elaborate a little on that today. I don't want you to get the impression that the future of how the Standard and MultiCore versions merge or diverge isn't on my mind
A key difference (pun sorta intended) with MultiCore is that requires you to use a 'multiton key' when you call getInstance(). This is because the a unique set of the Facade, Model, View and Controller instances will be managed for that key, and you can have as many of these 'Cores' as you like. This helps us leverage loaded swfs or Flex Modules to allow completely isolated PureMVC apps to be running side by side.
But if you just want a simple app, I've thought perhaps this Multiton concept is a bit heavy. And particularly in languages and platforms that don't support modular programming at all, it really would be overkill.
Sure it's not much of a requirement to pass in a string for your application name. But dropping the Standard version and forcing a migration of existing apps after the 2.0 migration is not really kind. The Standard version remains the simplest implementation of the concept and the most easily ported. And it's the reference for all the other ports at the moment as well and minor enhancements and bug fixes have to be able to be followed on those lines without having to switch to a MultiCore implementation.
So as is now outlined on the PureMVC.org About page, there are 2 versions, and they'll both continue to be maintained. MultiCore may be allowed to diverge based upon its unique needs. The question for the AS3 developer becomes
what is the recommended version? Up until now, this has been the Standard version, because the unit tests weren't even ported yet. I've done that but am adding a few MultiCore specific tests now.
Porting the unit tests over, I discovered that unit testing is much easier because you can get a fresh 'Core' for each test by simply using a unique string, so you don't have to worry about setup / teardown approaches and order of tests to keep from mucking up the notification namespace and observer lists in successive tests. Once that is done, and MultiCore moves to Production status, I believe the benefits it lends to unit testing will be enough to recommend it over the Standard version for new projects.
Migrating from the latest release of the Standard version to the latest MultiCore release is currently a matter of:
0. Replacing the swc or source code for PureMVC.
1. Changing imports statements from
'org.puremvc.as3' to
'org.puremvc.as3.multicore' 2. Moving any facade access out of Proxy and Mediator constructors and into initializeNotifier or (preferred) onRegister.**
3. Using a unique string for a key when calling 'facade.getInstance()'.
(i.e. Give your app a NAME, similar to Mediators or Proxies)** Deferring facade access in Proxies and Mediators until onRegister() is a recognized best practice since the introduction of onRegister. This allows us to be sure the actor is ready to participate in any coversation it starts by whatever method of action (i.e. notification, registration, retrieval, etc.) In MultiCore, the earliest the facade property is available to any Notifier subclass is initializeNotifier, not during the construction phase. -=Cliff>