Hi all,

I've been working on my application as a PureMVC project for a couple of months now, and I have been having an architectural quandary in my mind for some time.  I'm wondering why the elaborate use of notifications is necessary.  It seems that when it comes down to it, they are just an abstraction of method calls, consolidated into a centrally accessible facade.  To explain my point, imagine a notification inside my app:

:

var body:MyNotificationData = new MyNotificationData(myValue);
this.sendNotification(ApplicationFacade.MY_NOTIFICATION, body);

this eventually makes its way to my mediator in the handleNotification( note:Notification ) handler:

:

override public function handleNotification( note:INotification ):void        
switch ( note.getName() ) {
case ApplicationFacade.MY_NOTIFICATION:
this.onMyNotification(MyNotificationData(note.getBody()));
break;
}
}
 
private function onMyNotification(body:MyNotificationData) {
var myValue:String = body.myValue;
// Do something with myValue
}
This is the best way that I've found to maintain strict data type-checking and abstract functionality for notifications.  It works great, but it seems like its a lot of extra work and calls which could be minimized.  As I've been working on this, I think the following kind of structure would work pretty well, and I'd like to know if someone can spot some serious flaws in my logic.  This strays from the PureMVC way of doing things (specifically, in the notifications being string ids, and in commands being called via the complicated command sequence.  I'm also not considering MacroCommands because I think that you can essentially simulate MacroCommands by sequencing commands functionally in the facade), so I'm not looking for critiques on my adherence to it.  I am mainly looking to see what factors I'm not considering here, which will make my architecture suck:

ApplicationFacade:

:

public function getMyMediator():MyMediator {
    return this.retrieveMediator(MyMediator.NAME as MyMediator)
}

public function notifyMyNotification(body:MyNotificationData) {
    getMyMediator().onMyNotification(body);
}

onMyNotification would be set to public instead of private, obviously, for this to work.  Commands could be invoked similarly:

:

public var myCommand:MyCommand = new MyCommand();

public function notifyMyCommandNotification(body:MyCommandNotificationData) {
    myCommand.execute(body);
}

instead of using the commandMap lookup in the Controller.executeCommand.  In this case, the notifications would be accessed with ApplicationFacade.getInstance.notifyMyNotification(body) instead of this.sendNotification(ApplicationFacade.MY_NOTIFICATION, body).  In both cases, you have to access the facade's static methods.  The reason I'm opening up this conversation is mainly that I see problem in the String id lookup that currently exists (it's so easy to screw up notifications when you refactor the notification name, for instance, but not the notification value), and I'd like to see stronger type-checking.  It's so easy to just note.getBody() and use it as an Object, which will work fine in many cases, even when you're not accessing a property properly.

The reduction of code that I see in this kind of a notification model would be:
This would:

- Remove the need for the listNotificationInterests method in Mediators and Proxies and the redundancy therein.
- Remove the need for handleNotification method in Mediators and the redundancy therein.
- Consolidate the list of notifications inside the ApplicationFacade to one place, the function which would invoke it.  No need to synchronize the list of notifications with the registerCommand counterparts.
- Remove the need to synchronize the name of the notification id values with the notification id const name.

I guess I'm wondering if a new (or branched) framework would be a good idea, based very strongly upon PureMVC, but not using Notifications because of the reasons that I mentioned above.  The main drawback is that it removes some of the concrete structure from the framework and requires that the coder adhere to existing standards, but I think that, since it would all be contained within the ApplicationFacade, for the most part, it would not be a problem. Please tell me your thoughts. 

Thanks,
umop

Cool.  Good to know.  But architecturally, this sequence looks alright?  (ie. It's not cutting corners on the using commands vs. local methods?)

Thanks,
umop

Hi Folks,

I am in the process of finalizing my (AS3) architecture for a game, and I just wanted to get a sanity check / some ideas to make sure that I made the best decisions and reduce the number of factors that I'm not considering.

This is a multiplayer game.  The entire game is a single component, not architected with PureMVC.  I put it together before I decided to go the PureMVC route, but it seems to work just fine this way.

Here is an example of the life-cycle of a drag of an item which is supposed to create a holder (I'm calling a "stack") for the item during dragging on both players computers:

• Drag event happens on an item (view component).
     
  • View dispatches an event which is caught by the game mediator in the function onUIStartDrag
• gameMediator:
     
  • onUIStartDrag figures out details about the drag (what is being dragged and the parameters - whether it was  a part of a selected series, etc) and then sends a LOCAL_STACK_CREATE notification which executes the LocalStackCreateCommand command.
• LocalStackCreateCommand:
     
  • Gets an id for the new stack from gameDataProxy
     
  • Creates a new stack visually by calling gameMediator.createStack(...) with the new id which creates the stack visually via the view component.
     
  • Calls gameDataProxy.remoteCreateStack(...)
• gameDataProxy.remoteCreateStack:
     
  • Constructs a message with data and sends it to the server
• gameMediator.onUIStartDrag sets up this stack as the dragging stack, locally so that it follows the mouse until it's dropped.

*** meanwhile, on the other computer ***

• Server transport dispatches an event with the incoming command which is caught and handled by gameDataProxy.handleCommand
• gameDataProxy.handleCommand calls gameDataProxy.handleRemoteStackCreated which send notification REMOTE_STACK_CREATED which executes RemoteStackCreatedCommand command.
• RemoteStackCreatedCommand calls gameMediator.createStack with the stackId from the server which creates the stack visually via the view component (see above call on other computer)

My immediate questions are:

1. I could have (and even started to) put the logic currently in onUIStartDrag into a command UI_START_DRAG.  I reverted this because:
    a. Debugging with
        org.puremvc.as3.core::Controller/executeCommand       
        Function/http://adobe.com/AS3/2006/builtin::apply [no source]       
        org.puremvc.as3.patterns.observer::Observer/notifyObserver       
        org.puremvc.as3.core::View/notifyObservers       
        org.puremvc.as3.patterns.facade::Facade/notifyObservers       
        org.puremvc.as3.patterns.facade::Facade/sendNotification       
        org.puremvc.as3.patterns.observer::Notifier/sendNotification 
      strewn all over the place is kind of a distraction when you trying to see what's going on in the stack, and I wanted to minimize it.
    b. Creating each command takes extra time to code
    c. Refactoring commands if I change my mind mid-project takes more time than refactoring a single method
    d. I figured that if I do have a business case for a command over a method, I can just move the code over then.
2. I decided to not create a command for the gameMediator.createStack either, for the same reasons.

What are y'all's thoughts on this kind of sequence?  I appreciate those who have read this far and any and all feedback that you have on this.

Thanks,
umop

This is my first posting in this forum, so I may be way off here, but I wanted to throw an idea out there.  This could very well have been discussed elsewhere already, so my apologies if I'm being redundant on any of it.  I'm also very new to PureMVC, so I might be fundamentally wrong on something.  However, this seems like a reusable possible solution for data which may or may not be loaded at the time a form (or any visual object with children) has presented itself:

- State/Province view notifies that it's ready to populate fields to mediator
- State/Province mediator sends a notification to a command which:
    - Gets the proxy
    - Asks the proxy for cached results
    - If the cached results exist, just trigger sendCachedResults command through a notification (below)
    - If the cached results do not exist:
        - Proxy makes a request to the server to get the States/Provinces and sends a LOADING_DEPENDENCIES notification in case any of the mediators want to display a progress indicator.
        - Upon return of results from server, proxy caches results and triggers sendCachedResults command through a notification (below)
    - sendCachedResults command: sends notification of cached results to interested parties

Is it even possible that much of this could be generic so that the code could be reused multiple places and use the same commands and notifications, just changing the type on the notification for delivery.  If there is a concern about mediators / views which are not currently shown being given data out of turn (for performance reasons or memory constraints, etc), the mediators could check for their focus or visibility and ignore the notification if necessary.

Just an idea.  Your thoughts?