Hi,

Is there any reasoning behind why the `execute` method of the MacroCommand is marked `final`? I've at times found the need to override the `execute` method to execute sub-commands *along* with executing some additional functionality. Something along these lines:

:

class MyCommand extends MacroCommand
{
override protected function initializeMacroCommand( ) : void
{
addSubCommand(FirstCommand);
addSubCommand(SecondCommand);
addSubCommand(ThirdCommand);
}

override public function execute(notification:INotification):void
{
super.execute();
sendNotification(COMPLEX_INITIALIZATION_COMPLETE);
}
}

In the absence of the above setup, I'd have to do something like:

:

class MyCommand extends MacroCommand
{
override protected function initializeMacroCommand( ) : void
{
addSubCommand(FirstCommand);
addSubCommand(SecondCommand);
addSubCommand(ThirdCommand);
addSubCommand(ComplexInitializationCompleteCommand);
}
}

public class ComplexInitializationCompleteCommand extends Command
{
    override public function execute(notification:INotification):void
    {
        sendNotification(COMPLEX_INITIALIZATION_COMPLETE);
    }
}

Thoughts?

Hi,

My module which has a facade of its own (ModuleFacade) looks something like this:

:

<mx:Module>
  <mx:ViewStack creationPolicy="auto">
    <mx:View1 />
    <mx:View2 />
  </mx:ViewStack>
</mx:Module>
The page loads, the facade is kicked in action, the module mediator is registered, the module mediator receives the confirmation, another command is fired to register the View1, the mediator for view1 is registered and the control reaches the view1 mediator from the registration command. All this works fine. The problem comes when the user switches view. Since the creation policy of my view stack is auto (can't create all views at once), the view2 mediator registration happens before the view2 has been completely created and this results in an error when I try to access my view2 components after the startup command for the view2 completes.

I can attach a creationComplete event listener to the view2 and make the listener function look up the facade, send the notification to the module mediator which in turn would pick up view2 and send it for registration. But this doesn't seem like a very good approach, I mean referring/lookingup facade in each and every view instead of just the main view. Is there any other approach I can use to tackle this problem or is this the only choice?

TIA,
sasuke

Hi all.

When creating mediators for complicated views, the handleNotification method quickly gets out of hand and becomes overly complex when dealing with a bunch of notifications. Would it be a good idea to introduce the concept of handler classes for mediators which lead to even more cohesion [i.e. the handler responsible for handling notifications as opposed to Mediators]. Something along the lines of:

:

public interface IHandler
{
        function handle(notification:INotification);
}

public class NotificationHandler implements IHandler
{
protected var viewComponent:Object;

public function NotificationHandler(viewComponent:Object)
{
super();
this.viewComponent = viewComponent;
}

public function handle(notification:INotification):void
{
// Do nothing, just a base class for other handler classes
}
}

public class BaseMediator extends Mediator
{
protected var handler:IHandler;

override public function handleNotification(notification:INotification):void
{
// If the control reaches here means that the implementing
// class has not overidden the handleNotification funciton.
// Try to handle the notification if the IHandler is set
// otherwise just do a NO-OP
if(handler)
{
handler.handle(notification);
}
}
}

public class MyModuleHandler extends NotificationHandler
{
override public function handle(notification:INotification):void
{
// do something interesting here with the notifications
}
}

public class MyMediator extends BaseMediator
{
public static const FIRST_NOTIFICATION:String = 'FIRST_NOTIFICATION';

public static const SECOND_NOTIFICATION:String = 'SECOND_NOTIFICATION';

public function MyMediator(mediatorName:String=null, viewComponent:Object=null)
{
super(mediatorName, viewComponent);
}

override public function onRegister():void
{
handler = new MyModuleHandler(viewComponent);
}

override public function listNotificationInterests():Array
{
return [
FIRST_NOTIFICATION,
SECOND_NOTIFICATION
];
}
}
What do you guys think? If not this, then what else can be done to remedy the above scenario?

TIA,
sasuke

Hi all,

I was wondering as to why the concept of Notifications[publish/subscribe model] was used to implement async event handling? I mean, isn't it possible to actually emulate the Event handling framework already present in Flex,Java and provide a thin portable wrapper around them?

I did hear a while back that Cliff had some issues/complaints with the way event handling worked in AS3 and other languages and wanted to implement some other scheme. I'd like to hear as to what really went wrong with events and what architectural decisions/points were taken into consideration before going with Notification and not Events. Links/Articles/other references purporting the point would be awesome.

TIA,
sasuke

Hi all,

Recently I've been developing a multi-core PureMVC web application in Flex [i.e. more than one core is active at any given time]. When the user logs in the system, I set the user credentials in a User object which is cached by the UserProxy class [which maps to the User VO]. All this action happens in the main or the parent facade, for the sake of completeness, let's call it ShellFacade.

What would be a good design choice for making this cached User VO present in the UserProxy class [which is currently registered in the ShellFacade] available to other cores [e.g. facade XXX]? One way I can think of is to:

• Retrieve the UserProxy of the ShellFacade in the XXX facade startup command
• Register the user proxy in the XXX facade using the retrieved proxy

:

class XXXStartupCommand extends SimpleCommand implements ICommand
{
   override public function execute(notification:INotification):void
   {
      var userProxy:IProxy = ShellFacade.getInstance(ShellFacade.NAME).retrieveProxy(UserProxy.NAME);
      facade.registerProxy(userProxy);
      // remaining code
   }
}
This of course creates a dependency of ShellFacade in the facade XXX command which seems a bit problematic since it hinders the reuse of this independent module in other scenarios. Is there any other way of doing this? Any design pattern which I can apply to reduce the coupling which would get introduced here?

I perfectly understand that it wouldn't be a big thing to change the ShellFacade to something else in case I decide to use the facade XXX in some other scenario but I'd like to avoid that. Suggestions welcome.

TIA,
sasuke

Hello everyone.

As far as my understanding goes, the mediator has the responsibility of mediating or orchestrating the components or the core actors of the PureMVC framework. So for e.g. if you would want to retrieve a piece of data from the database on your submit button, an event is dispatched from the button which is handled by the mediator which in turn:
- uses the cached proxy to make the webservice call OR
- fires off another notification which triggers or executes a command which in turn makes a webservice call

But is it logical to fire off local events to the mediator? By local events I mean events which don't need to interact with the PureMVC machinery and can complete on their own. For e.g. if on the click of a radio button I want to do some set a view property[ a variable declared in the script tag of the MXML file] to the value of the radio button, should I fire off a custom event on the click of the radio button which would then be picked up by the mediator or can I just write a handler method in the script tag which does all the processing without going to the mediator? Is is required that *all* events which the view is interested in capturing need to be dispatched to the mediator?

TIA,
sasuke

Hi all, a puremvc beginner here.

A really quick question; is it a wrong thing or a bad practice to remove a mediator or de-register it from within itself?

The big picture: In my application, all my views implement a common interface 'IViewComponent' which has a cleanup method. As soon as the view needs to be swapped out, the parent mediator invokes the cleanup method on the view, which in turn sends an event to the mediator which in turn does all the cleanup [typically this involves clearing the form fields, grounding all VOs, re-setting page state and finally unregistering the mediator].

I could have avoided this by:
- removing the mediator in the parent mediator itself
- retrieved the reference to the facade in the view [Facade.get...] and then removed the mediator
- fired off a command to do the removal; but this kinda makes the the 'resetting the page state' part difficult to handle [clearing the view from the command doesn't seem like a good idea]

Any suggestions or thoughts would be really appreciated.

-sasuke