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.

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.

Hi,

Having read through the best practices (and got quite excited), I downloaded the architecture 101 demo, but I am a little confused.

1. How come the Mediators are directly accessing the Proxies. Shouldn't they use a command?

2. Why does DeleteUserCommand send a notification for USER_DELETED. Surely it would make more sense for the proxy to send it when a user is deleted?

I'm really impressed by your emphasis on documentation and demos. So many other frameworks are crippled by a lack of learning material. The best practices is really well written and very helpful.

Thanks