PureMVC Architects Lounge

Milos pointed out here:

http://forums.puremvc.org/index.php?topic=311.msg1212#msg1212

...that you can't talk to the facade inside the constructors of your Notifier subclasses (Mediator, Proxy, SimpleCommand) now, you must do any facade access in the initializeNotifier method.

This is mentioned in the ASDoc for MultiCore and is shown in the demo, but is worth pointing out explicitly and will be elaborated on soon.

The pattern of having an initializeSomething method that is called from the framework class constructor and used to initialize the subclass is in keeping with other classes in the system:

• Model.initializeModel
• View.initializeView
• Controller.initializeController
• Facade.initializeFacade
• Facade.initializeModel
• Facade.initializeView
• Facade.initializeController
• MacroCommand.initializeMacroCommand
• and now:
• Notifier.initializeNotifier

It keeps the constructor clean, which helps make easily Notifiers easily subclassed.

For instance if you prepare and call a service from your MyProxy constructor then a subclass of MyProxy cannot do the required call to super to pass its name and data object up to the Proxy superclass without executing the unwanted code in the MyProxy constructor.

-=Cliff>

I went around this issue by overriding the onRegister method and then accessing the Facade there. It seems to work, but I don't know if there are any issues by using this method (I don't expect it  :P).

onRegister comes after initializeNotifier, and is the recommended place to do any preparatory facade access (same for Standard version, though the demos haven't yet been changed). This insures that any 'conversations' that are started only happen once the actor is registered and capable of being retrieved or notified.

-=Cliff>

ello,

I wrote a bit more about this issue here - http://lowpitch.com/blog/2008/07/23/puremvc-multicore-vs-standard-singlecore/ . I guess it's a sign of a well designed system that so few changes have to be made to port from singlecore to multicore.