it's just a mapping to a class not an instance of a class

Ok. I hold my hands up. This is very true.

What can those commands be doing as a result of every Proxy's success / failure that couldn't be done inside the Proxy itself?

These commands allow the StartupManagerProxy or whatever else is managing startup to react to the Proxy's initial aquistion of data. For example if a Proxy hitting a remote service failed to aquire the data, a second proxy could be used which aquires the data from another source. Essentially I want one Proxy to be able to monitor the initialisation of the others. I have always faught the temptation to use a bastardised Mediator for this job (The fact it can recieve Notifications makes it ideal for monitoring other Proxies), and I have never liked the StartupManager utility.

I don't think I'd want to modify the core framework (and all the ports that depend on it) in such a fundamental way, though.

I fully understand that. The simplicity is the reason I use PureMVC and at this point in its life I wouldn't suggest any such a change. However, a small change could be made that would have no impact on complexity or in the frameworks behavior.

I cannot get my head around the storm of Commands that you are describing.

Its exactly to prevent a storm of commands that I am dynamically registering commands. In the example I mention above there are just 3 Commands - HandleSuccessCommand, HandleFailiureCommand and HandleProgressCommand that are dynamically registered for each IStartupProxy. To me, this is hugely economical. Far more economical than a separate set of Commands for each IStartupProxy.

If you are concerned that you might be bumping an already-registered Command, then do a facade.hasCommand(noteName) before registering it.

As I mentioned in my first post, I have done exactly this, but once I have established that there is already a Command registered, there is nothing I can do about that fact. I would like to be able to remove the command and re-register it within a MacroCommand along with the Command that would have bumped it off, but there is no way I can get the Command class as removeCommand() return void. Now if removeCommand() just returned the Command class…

There have been many things that I've wanted changed in pmvc over the years that I have come to see as strengths rather than weaknesses, but in this case, what seems to me like a reasonable way of working is prevented by the framework. I certainly don't expect you to make changes to an already excellent framework purely on my account, but I find this an interesting point of discussion.

Life is good. Been keeping my head down and getting on with things, but should have a lot more time for the important things (Like pmvc) now.

As for a use case, I'll start with a generalisation. Its no secret that Notifications are pmvc's Events (To a degree), so I can't help but translate the one note / one command ratio to Flash's Event model. To me, the silent superceeding of a previously registered Command by a newly registered Command is like a Class registering for an Event and by doing so, unregistering another class. This seems to be a dangerous precident, especially on a larger project with many people working on it. Personally I can't see a problem with a one to many ratio of Notes to Commands - It would be easy enough to order by registration order or even to allow registration at a particular point  - Controller.registerCommand(command, executionPosition), or perhaps to weight a Command - Controller.registerCommand(command, weighting). That said, I understand that the latter two solutions would add an element of complexity where it is perhaps not needed.

A second use case would be at Startup. I seem to reinvent startup management every time a start a new project and I feel like I've tried a lot of different setups over the years. Essentially I want to be able to say:

StartupManagerProxy(facade.retrieveProxy(StartupManagerProxy.NAME)).registerProxy(galleryProxy, [settingsProxy, assetProxy]).

Where the second argument is an array of dependences. I then want my StartupManagerProxy to take the registered Proxy (an IStartupProxy with an aquire() and a getStartupNotificationNames() method which returns its result, fault and update notification names), and manage its place in a sequence based on its dependencies and the number of simultaneous connections etc.

In order for the StartupProxyManager to be informed as registered StartupProxies dispatch Notifications, I have it firing a Notification that triggers a Command that registers a set of other Commands which are fired by the Notification names it got through calling getStartupNotificationNames():Array). This way, the StartupManagerProxy is notified when its StartupProxies aquire or fail to aquire their data. My problem lies here. As the StartupManagerProxy is (indirectly) dynamically regsitering these Commands, it is very possible that somewhere else in the application a Command that is listening for these same Notifications gets bumped.

Currently I deal with this situation by having all StartupProxies append a predefined suffix onto their declared notification names when they are retrieved via getStartupNotificationNames():Array. A suffix which only the StartupManagerProxy's Commands are looking for.

The StartupManagerProxy then consumes these Notifications, clones them, strips the suffix and redispatches them. This way, any other Commands still get the Notifications.

Sorry. That was a little longer than I expected, but it hopefully makes sense. I can also give you good use-cases when using application-wide state management, though that would be little more complicated to explain.

Hey Cliff,

Been a while  .

Had a couple of situations lately where I've found the 1 Command to 1 Notification situation problematic. Obviously if you know in advance that you're going to need multiple Commands to respond to a single Notification, you use a MacroCommand, but when you are registering Commands dynamically, it is easy to inadvertantly bump a previously registered Command out of the way with a new one.

To be more specific, I have a Command that registers other Commands to listen to a Proxy's Notifications. Due to the dynamic nature of the setup, it is possible that there might be have been other Commands registered for the same Notifications. I immediately thought a safe way of dealing with this would be to check to see if there are already any Commands registered with the View, and if so, remove them, then place them (Along with the newer Command) into a MacroCommand and reregister that. This would ensure that nothing ever gets bumped. The only problem is that there is no way to retrieve the Command class from the Controller - Controller.hasCommand() returns a Boolean and Controller.removeCommand() returns void.

I find increasing use in dynamically registered Notifications, and it seems to me that this is a fair use case for either the Controller accepting multiple Commands for a single Notification or for the Controller offering access to a registered Command's class.

Howdy,

Got to do some serious deserialising from XMLNodes. Built a set of deserialisers that strip the needed data from the node and build fully typed objects accordingly. At the moment I have Proxies consuming the XML and handing off the nodes to the rellevant deserialiser, then offering the returned classes up through their api's.

This has created some dependencies between Proxies - some of the deserialisers rely on objects built by (or cached) by other Proxies. It all works nicely but I just suffered a pang of uncertainty. Should the proxies only offer up the xml, with Commands doing the deserialising?

James Knight has ported the unit tests to As2 and they are now available form The Manifold Project.

2.0.3 is now available. It contains an important change which will break backwards compatibility.

As with the original AS3 version, you now pass class references when registering commands rather than an instance of the command. Please see the release notes for more details.

Hi tjiddy,

You might be interested in:

 http://www.herrodius.com/blog/category/prana.

and specifically:

https://prana.svn.sourceforge.net/svnroot/prana/prana-sample-puremvcArch101Demo/trunk

Howdy,

If anyone out there is using the mighty FDT, I have made a set of templates which you can get here:http://www.darkandlong.com/pmvc/pmvc_as3_templates.xml. SaveAs the link as it is an xml file.

You can import it into FDT via preferences/FDT/editor/Templates - Import...

Will add to and improve when I can.

I've just committed version 2.0.0 to the SVN. Have given it a quick set of tests and all appears to be ok.

Please let me know if you find any errors.

Just updated the SVN with changes bringing the AS2 port in-line with the AS3 version.

Have tested it with an old project and all seems to be working fine.

Any issues, let me know.

Why not subclass Notification and add your own getter / setters much as you would when building a new Event class?

The getBody() is there as an easy, untyped way of passing data, but if you need  strict typing, just add it to your subclass.

Happy to send you an example if needed.

Hi Cliff,

Been having a think about lazy instantiation vs passing in instances of commands in an AS2 version.

How about if instead of passing in instances of commands, we passed in instances of command factories. Each factory would extend an Abstractfactory class, filling its one empty public command 'createCommand()' with code creating a concrete command and calling execute() on it. When passed in, the factory could be mapped to a notification, just like commands are at present. The controller could then call createCommand() on the relevant factory whenever it needed to instantiate a command, allowing lazy instantiation to be retained.

Hi,

Re. The Facade, only that it was having a Class datatype passed through it via the registerCommand()

Definately makes sense to pass instances in which would solve that problem.

Actually went through all the code last night, and it looks like a really easy job to port excepting the problem with the commands. Only other problem I can see is the use of constants, but could just switch them to private vars with only a getter. Oh and changing void to Void

Just out of interest, why don't you cache the commands in the controller once they are created?

Hi,

Having had a good look at the code, I can see one big problem with a port - the passing of command classes into the Controller for later instantiation. This also effects the Facade and MacroCommand classes. As2 doesn't allow the use of a Class datatype so how to create the commands on call? The only alternative seems to me to hard-code them into the Command class for each project and any MacroCommands or use a factory, but that is ugly.

What do you think?