Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Show Posts

* | |

  Show Posts
Pages: [1]
1  Announcements and General Discussion / General Discussion / Using more commands. on: July 27, 2009, 06:58:41
We're having a bit of a in-office debate on PureMVC best practice, and I wanted to get an opinion on the way I've historically been using PureMVC. I'm using the login form example from the best practice document.

I prefer to map the LOGIN_SUCCESS and LOGIN_FAILED notifications to their own SimpleCommands (eg: LoginSuccessCommand and LoginFailedCommand). These “extra” commands would call retrieve and call public methods on the LoginMediator (eg: LoginMediator.onLoginSuccess and LoginMediator.onLoginFailed) as opposed to using the LoginMediator.handleNotification switch statement.

I like this for a few reasons:

In large applications, it centralises the code into “actions” (or verbs, as I like to think of them). If I want to change the way that the application reacts to the “successful login” action, I can simply find it in one place (i.e.: LoginSuccessCommand), and have total control over which order things happen in. In the best practice example, if multiple mediators needed to react to the same notification, I either need to remember where these are or search for all matches for a notification to edit them, and I can't control the order they happen in.

Additionally, I can easily update a Proxy and a Mediator at the same time in a predetermined order. Say I needed to check or update a data object containing the application’s state (AppStateVO via AppStateProxy, for example). My LoginSuccessCommand could then call public methods or getters on the AppStateProxy before it updated the LoginMediator. If things get really complex, I would use a MacroCommand, but this is the general way I’ve been approaching this problem.

What are the issues (if any) with this from a best practice standpoint? I now do this so often that most of my applications do not utilise Mediator.handleNotification at all. I opt instead for three or four line Command.execute methods that simply retrieve Mediators and call public methods on them, exactly the same way that is recommended for using a Proxy.

Any thoughts from a best practice standpoint would be much appreciated.

Cheers.
2  Announcements and General Discussion / General Discussion / Mediator best practice. on: January 13, 2009, 06:15:51
Since day one of using PureMVC, I have passed through a display object container as a Mediator constructor's viewComponent parameter (instead of creating a UI component before creating the mediator, as in the HelloFlash code example). A colleague pointed out that this is "incorrect". An example:

Say I have a command, which creates a Mediator:

SimpleCommand.as:

:
override public function execute(note:INotification):void
{
var stage:Stage = note.getBody() as Stage;
facade.registerMediator(new TestMediator("test", stage));
}

And in the constructor of said Mediator, I create a display object:

SimpleCommand.as:

:
private var _sprite:Sprite;

public function TestMediator(mediatorName:String = null, viewComponent:Object = null):void
{
super(mediatorName, viewComponent);
_sprite = new Sprite();
viewComponent.addChild(_sprite);
}

If I do it this way, I only put a reference to my UI component inside its mediator, not inside the command that creates it. Also, I can remove it from the stage, even delete it and re-create it if necessary.

Here's how I'm being told to do it:

SimpleCommand.as:

:
override public function execute(note:INotification):void
{
var stage:Stage = note.getBody() as Stage;
var sprite:Sprite = new Sprite();
stage.addChild(sprite);
facade.registerMediator(new TestMediator("test", sprite));
}

So, my question is... Why does it work this way? If I remove my TestMediator, I am still left with a sprite that has no direct references and no instance name, and therefore, no way to remove it from the stage!

Also, I much prefer to link my mediators to my UI components (which are intrinsically linked anyway) rather than putting them in stateless commands or unrelated mediators.

Am I totally missing something here?

Thanks.
Pages: [1]