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

Pages: [1]
Print
Author Topic: Why notifications?  (Read 5603 times)
Eric Arnold (umop)
Newbie
*
Posts: 4


View Profile Email
« on: October 18, 2009, 05:51:19 »

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
« Last Edit: October 18, 2009, 06:37:33 by Eric Arnold (umop) » Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: October 19, 2009, 06:35:11 »

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,

Notifications aren't an abstraction of method calls. The sender doesn't know the receiver - that's the whole point - to decouple sender and receiver with a publish / subscribe system.

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

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

Extend this thinking out until you have 20 mediators or more. That Facade is going to be pretty unwieldy.

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.
I'm sorry to say that ripping out the notification system isn't something that's ever likely to happen. It is central to the PureMVC design, and one of the chief reasons for its portability. There are 90+ projects on the site right now, including ports to other languages depending on the AS3 reference implementations working as they do. Not to mention the fact that people all over the world are using this thing as is and understand the accumulated best practices for its use.

Of course the world always has room for one more framework; it seems a new one comes out every day or so now. You could just wait for the one that resonates best with you, or forge out on your own as I did and implement your vision.

-=Cliff>
Logged
Pages: [1]
Print