More on organizing Notifications...

[sideDoor]

I was wondering what you thought of this post about organizing notifications:

http://labs.almerblank.com/2009/11/organizing-puremvc-notifications/

I like the idea of a Notifications Class, typed to INotifications that implements:

function register():void;
function remove():void;

But the last suggestion in this post is also interesting, by aggregating notifications specific to areas of an application in an all encompassing Notifications Class, which could be accessed through the facade.  However, I'm not certain about breaking from the best practice of using public static constants in the concrete Notification Class (LoginNotifications) and instead using only public constants.

Please see the above post...

Could you advise on best practice here?  Thanks!

[puremvc]

I think it is a good way of doing it, but I haven't actually implemented based on it just yet. Your constants are still public static, they're just defined on a different class.

-=Cliff>

[sideDoor]

Actually, if you have a glance at this fellow implementation, you'll notice he's suggesting using public const and a intermediary Class between the Facade and the individual notification Classes:

http://labs.almerblank.com/2009/11/organizing-puremvc-notifications/comment-page-1/#comment-13

What do you think of this?

Thanks man!

[puremvc]

What do you think of this?

Definitely interesting. Possibly, a smidge too complex to push on everyone as a best practice (anything more complex than tab a/slot b and lots of folks run screaming), but definitely worth investigating. It does look sensible.

-=Cliff>

[sideDoor]

Thanks, I'll try it out on my current project and report back...I see it being pretty beneficial for modules, where you can squirrel away your notifications per module...

[puremvc]

I definitely look forward to hearing your experiences with this approach...

-=Cliff>