PureMVC Architects Lounge

Announcements and General Discussion => General Discussion => Topic started by: lizardruss on July 16, 2007, 02:13:32

Title: Custom Notifications
Post by: lizardruss on July 16, 2007, 02:13:32
I work in a team environment where I believe it will be beneficial to have custom Notification objects with typed payloads.  For example, I'll have a LoginNotification that would carry a username and password.

The primary reason is so other developers on my team can look at the Notification's definition and know exactly what information they can expect from it.  This way once all the notifications are laid out for an application, my team can code away without needing to check with one another to know what information a notification will contain etc.

The decision I'm faced with is where to put the Notification classes.  Initially I thought that I would put them with the components that send them, but soon found that locating a particular Notification wasn't intuitive.

A second approach is to put the Notification classes in the same package as the ApplicationFacade.  This is similar to defining all the names of your Notifications as static constants within the ApplicationFacade.as file.

A third possibility is to simply add a 'notification' package along with the 'model','view', and 'controller' packages.

Has anyone else had taken the custom notification approach?  Have any suggestions on how to organize the Notification classes?

Title: Re: Custom Notifications
Post by: puremvc on July 16, 2007, 04:55:06
You're absolutely right in your reasoning for using custom Notifications. In Flash, you're forced to extend Event if you want a payload, and knowing that some people really don't like having to create the extra classes, I felt it was the right thing to have the base Notification class have a Object payload, but support subclassing if you want to.

As for where to put them, I believe that adding the Notifications at the same level as ApplicationFacade makes the most sense. They have to live somewhere, nothing else is expected at that level, and they are potentially shared by all 3 tiers. That was the reasoning for putting the ApplicationFacade there.

Adding another branch at the MVC level is not really advised. The Cairngorm package structure forces only 2 more folders on you at the MVC level, but every time I find myself at that folder level in a drill down, I find I have to stop and think. Only for a second, but it adds up.

See this related discussion:
http://forums.puremvc.org/index.php?topic=8.0 (http://forums.puremvc.org/index.php?topic=8.0)