Over 10 years of community discussion and knowledge are maintained here as a read-only archive.
// inside the Controller //private var _mapNotesToCommands:Dictionary = new Dictionary();public function registerCommand(note:String, commandClass:Class):void{ if (_mapNotesToCommands[note]) { var commands:Vector.<Class> = _mapNotesToCommands[note] as Vector.<Class>; if (commands.indexOf(commandClass) == -1) //prevent the same command being registered twice for the same note // commands.push(commandClass); } else { _mapNotesToCommands[note] = Vector.<Class>([commandClass]); }}public function executeCommand( note : INotification ) : void{ var commands:Vector.<Class> = _mapNotesToCommands[note.getName()] as Vector.<Class>; if (commands) { for (var i:int = 0; i < commands.length; i++) { var commandClass:Class = commands[i]; if ( commandClass == null ) continue; // perhaps give the option of loggin here // var commandInstance:ICommand = new commandClass() as ICommand; commandInstance.initializeNotifier( multitonKey ); commandInstance.execute( note ); } } else { // perhaps give the option of loggin here // }}
The simple fact that a developer can join my team and unwittingly overwrite a notification to command mapping by registering a command somewhere deep in the life-cycle of an application, and thereby change expected behavior or introduce hard to track bugs, is seriously problematic.
I'm still not understanding why you'd opt for this restriction.
As well, I'd prefer to see an Enum-type Object used instead of Strings to represent notifications,
This is why generally, commands are generally registered once at the beginning of the application.
...'somewhere deep in the life-cycle of an application' is not the place to be registering commands. It indicates you already have a spaghetti-code project.
anyone can at anytime unwittingly un-register a command at any time
If an ICommand has already been registered to handle INotifications with this name, it is no longer used, the new ICommand is used instead.
if (! facade.hasCommand( MY_NOTE )) facade.registerCommand( MY_NOTE, MyNoteHandlerCommand);
What would be wrong with implementing the registering, executing, and un-registering commands to notifications as illustrated above [un-mapping not shown]? Wouldn't that be more flexible? How would that kill the Pureness of PureMVC?
Extend the View class, override the methods you want to change and in your ApplicationFacade, override the initializeView method and instantiate your own View sublcass
initializeController () method protected function initializeController():voidInitialize the Singleton Controller instance.Called automatically by the constructor.Note that if you are using a subclass of View in your application, you should also subclass Controller and override the initializeController method in the following way:: // ensure that the Controller is talking to my IView implementation override public function initializeController( ) : void { view = MyView.getInstance(); }
// ensure that the Controller is talking to my IView implementation override public function initializeController( ) : void { view = MyView.getInstance(); }