Organizing PureMVC Notifications

Nov 3, 2009 Author: Omar Gonzalez

Organizing PureMVC Notifications

One of my favorite things about using PureMVC as my application framework are the standards established for organizing application code. For notification names the common ways that I have seen these organized is by declaring constants on the concrete Facade, or by externalizing them to external classes. I have tried both approaches, but my preferred method is to externalize the constants to notification classes. Not only do I feel like its more organized because the notification names for a section of the application are centralized to different notification classes. But, it is also a good way to clean up the amount of imports in the concrete Facade and centralize the Command registrations to these notification classes.

package com.project.controller.notifications
{
	import com.project.controller.commands.LoginCommand;
	import com.project.controller.commands.LogoutCommand;
 
	import org.puremvc.as3.interfaces.IFacade;
 
	public class LoginNotifications
	{
		static public const LOGIN:String = "LOGIN_NOTIFICATION";
 
		static public const LOGOUT:String = "LOGOUT_NOTIFICATION";
 
		public function LoginNotifications( facade:IFacade )
		{
			facade.registerCommand( LOGIN, LoginCommand );
			facade.registerCommand( LOGOUT, LogoutCommand );
		}
	}
}

Above is an example of a notification class. The constructor requires an IFacade object that it uses in the constructor to map notifications to commands using the IFacade object that is passed into the constructor. You can see how a bigger group of commands can be nicely organized into this class. Below is an example concrete Facade.

package com.project
{
	import com.project.controller.notifications.LoginNotifications;
 
	import org.puremvc.as3.patterns.facade.Facade;
 
	public class ProjectFacade extends Facade
	{
		public function ProjectFacade()
		{
			super();
		}
 
		static public function getInstance():ProjectFacade
		{
			if (!instance) instance = new ProjectFacade();
 
			return instance;
		}
 
		override protected function initializeController():void
		{
			super.initializeController();
 
			new LoginNotifications( this );
		}
	}
}

In the example above we can see the usage example for the notifications class for the login group. In the override for the initializeController() method, after initializing the controller, a LoginNotifications object is started with a reference to the IFacade instance that is the concrete facade, or simply "this". The amount of imports is reduced in the concrete facade, and there are less lines required in the initializeController() method, creating a neater, shorter concrete facade class.

This kind of organization is almost always based on personal preference, this just happens to be mine. =)

Category: Code & Samples

Tagged: Actionscript 3.0, Code & Samples, Flash, Flex, Frameworks, pmvc, PureMVC, standards

17 Responses

Cliff Hall says:

November 3, 2009 at 6:58 am

Now here's a truly unique take on the eternal 'where to define notification constants' question!

I'll be trying this method out very soon. It certainly looks like a best practice to me. And props for putting the class in the appropriate package location

Bravo, Omar!
Omar Gonzalez says:

November 3, 2009 at 8:52 am

Wow, that's pretty impressive Cliff. I just posted this at about 1.30 am and your PureMVC blog post radar already found it… and its only my second post on our Labs blog!

Anyhow, thanks for the props and glad ya liked it. I was gonna send you a link to get your thoughts on it but you beat me to the punch.

Thanks Cliff!
Akos Papp says:

November 3, 2009 at 6:30 pm

Great article!

Thx,
A.

neil manuell says:

November 5, 2009 at 7:22 am

Yep this is cool

One of those oh how simple things that I never thought of myself.

lots of ideas comming

Can I suggest this?

package com.project.controller.notifications
{
	import com.project.controller.commands.LoginCommand;
	import com.project.controller.commands.LogoutCommand;
 
	import org.puremvc.as3.interfaces.IFacade;
 
	public class LoginNotifications
	{
		static public const LOGIN:String = "LOGIN_NOTIFICATION";
 
		static public const LOGOUT:String = "LOGOUT_NOTIFICATION";
 
                private var facade:IFacade
 
		public function LoginNotifications( facade:IFacade )
		{
                        this.facade = facade;
 
		}
 
                public function register():void{
                        facade.registerCommand( LOGIN, LoginCommand );
			facade.registerCommand( LOGOUT, LogoutCommand );
                }
                public function remove():void{
                        facade.removeCommand( LOGIN );
			facade.removeCommand( LOGOUT );
                }
	}
}

would that work? also it could implement an Interface,

nice idea omar

Omar Gonzalez says:

November 5, 2009 at 8:51 am

Thanks Neil.

Yea I did briefly at one point think about creating an interface for the class, but I prefer to not add any actors to the PMVC core if I don't absolutely have to.

I do like your suggestion to be able to remove them, which I would probably do for the cases where there are dynamic commands that get registered at runtime. Personally I don't do that very often at all, as most of my commands are almost always registered at startup. It would require a change in the concrete Facade to be able to remove them later though.
```
// In the concrete Facade class
 
// add a variable
public var loginNotifications:LoginNotifications;
 
...
 
override protected function initializeController():void
{
    super.initializeController();
    loginNotifications = new LoginNotifications( this );
    loginNotifications.register();
}
```
This way you can later access the LoginNotifications object to remove() them. Personally, I'll probably use this suggestion only when I add commands at runtime, which I don't really do that often.
neil manuell says:

November 5, 2009 at 10:40 am

Yes, horses for courses.

I tend to register my commands at State Entered and remove them at State Tear down.

again, thanks for the idea.
Tidy up those unsightly Notifications « says:

November 5, 2009 at 11:13 am

[...] GONZALEZ has come up with a really cool way of tidying up those nasty (and so necessary) notification constants. So simple you should have thought of it [...]
Will says:

November 5, 2009 at 2:51 pm

Your point about saving on imports in the Facade is a little odd. What you save on imports in the Facade you make up with imports in your Mediators, Proxies and Commands, right? You'll have to import the LoginNotifications class whenever you need to reference it's constances.

Don't get me wrong, I actually really like the idea of creating locial groups notifications and it certainly outweighs the imports issue. I'll probably try this on my next project. Thanks for sharing!

hasanotuome says:

November 5, 2009 at 7:03 pm

@Will,

If you use public const vs public static const in your Notification classes and then create instances of your Notification classes in your Facade, you won't need additional imports in your Mediators, Proxies or Commands as they will still be available via your concrete Facade.

You could further expand this approach by wrapping all your Notification classes in a Notifications class and letting this be the intermediary between your concrete Facade and Notifications.

package com.project
{
	import com.project.controller.notifications.Notifications;
 
	import org.puremvc.as3.patterns.facade.Facade;
 
	public var notes:Notifications;
 
	public class ProjectFacade extends Facade
	{
		public function ProjectFacade()
		{
			super();
		}
 
		static public function getInstance():ProjectFacade
		{
			if (!instance) instance = new ProjectFacade();
 
			return instance;
		}
 
		override protected function initializeController():void
		{
			super.initializeController();
 
			notes = new Notifications( this );
		}
	}
}

That's your modified Facade and here's the Notifications wrapper class:

package com.project.controller.notifications
{
	import org.puremvc.as3.interfaces.IFacade;
 
	public class Notifications
	{
		public var application:ApplicationNotifications;
		public var login:LoginNotications;
 
		public function Notifications( facade:IFacade )
		{
			application = new ApplicationNotifications( facade );
			login = new LoginNotifications( facade );
			// etc, etc...
		}
	}
}

And finally, your slightly modified Notification class:

package com.project.controller.notifications
{
	import com.project.controller.commands.LoginCommand;
	import com.project.controller.commands.LogoutCommand;
 
	import org.puremvc.as3.interfaces.IFacade;
 
	public class LoginNotifications
	{
		public const LOGIN:String = "LOGIN_NOTIFICATION";
 
		public const LOGOUT:String = "LOGOUT_NOTIFICATION";
 
		public function LoginNotifications( facade:IFacade )
		{
			facade.registerCommand( LOGIN, LoginCommand );
			facade.registerCommand( LOGOUT, LogoutCommand );
		}
	}
}

Each Notification class would still handle its command registration process and you would gain access to your Notifications using the notes attribute in your concrete Facade. Hope this helps…

Tweets that mention Organizing PureMVC Notifications - Almer/Blank Labs -- Topsy.com says:

November 6, 2009 at 11:20 am

[...] This post was mentioned on Twitter by Helio S. Junior and Nolan Butcher, Philip Heyde. Philip Heyde said: RT @H3li0: Organizing PureMVC Notifications – Almer/Blank Labs http://bit.ly/4nZYUf [...]
uberVU - social comments says:

November 6, 2009 at 7:54 pm

Social comments and analytics for this post…

This post was mentioned on Twitter by nebutch: My coworker at Almer/Blank wrote up a good article on PMVC notification organization. http://bit.ly/4EhPue…
Ódýr Vefhýsing says:

November 9, 2009 at 7:33 am

This is a really good idea! Thanks for the heads up and great work!

Regards,
Ódýr Vefhýsing
polykrom says:

November 14, 2009 at 11:19 pm

@hasanotuome

I've use your solution in my new application to define my notifications constants, but there was a problem because the concrete facade wasn't already accessible from my different mediators and proxies while registrating them, the facade returned null, so it was impossible to access my notifications vars.

So, i had to create a getter in my differents mediators and proxies to access the facade like this :

protected function get _facade():LoginModuleFacade
{
if ( multitonKey == null ) throw Error( MULTITON_MSG );
return Facade.getInstance( multitonKey ) as LoginModuleFacade;
}

don't know if it's the right way to do this…
Justin says:

November 16, 2009 at 7:47 am

Bookmarked! Love it.
neil manuell says:

December 1, 2009 at 12:10 am

@polykrom
if your framework actors do not have references to the facade, then they haven't initialised yet, override the onRegister method an put the code there. This will ensure that the facade is available
cheers
sideDoor says:

January 6, 2010 at 6:25 pm

Great stuff!

@hasanotuome:

Following your approach, how are you accessing the "notes" variable of the ApplicationFacade from within Mediators, Proxies and Commands?

Mediators, Proxies and Commands have the inherited instance-variable facade, a reference to the Facade supertype, but it is typed to IFacade, so, for example, we cannot use facade.notes.login.LOGOUT to get at the constant (notification name).

We can use ApplicationFacade.getInstance().notes.login.LOGOUT, but of course, we have to import our concrete ApplicationFacade class into each actor where needed.

What's your approach here?

Thanks,
jf
matt says:

May 18, 2010 at 5:33 am

Hey Hasan,

Cool addition with the public var notifications in the facade. If this was added to the framework it would remove the need to create concrete facades in many cases. Also the protected variable facade provided by the Notifier class would always allow access to all notifications. Thus also the dynamic adding and removing of commands could be solved that way.

Leave a Reply × Cancel reply

Cliff Hall says:

November 3, 2009 at 6:58 am

Now here's a truly unique take on the eternal 'where to define notification constants' question!

I'll be trying this method out very soon. It certainly looks like a best practice to me. And props for putting the class in the appropriate package location

Bravo, Omar!

Omar Gonzalez says:

November 3, 2009 at 8:52 am

Wow, that's pretty impressive Cliff. I just posted this at about 1.30 am and your PureMVC blog post radar already found it… and its only my second post on our Labs blog!

Anyhow, thanks for the props and glad ya liked it. I was gonna send you a link to get your thoughts on it but you beat me to the punch.

Thanks Cliff!

Akos Papp says:

November 3, 2009 at 6:30 pm

Great article!

Thx,
A.

November 5, 2009 at 8:51 am

Thanks Neil.

Yea I did briefly at one point think about creating an interface for the class, but I prefer to not add any actors to the PMVC core if I don't absolutely have to.

I do like your suggestion to be able to remove them, which I would probably do for the cases where there are dynamic commands that get registered at runtime. Personally I don't do that very often at all, as most of my commands are almost always registered at startup. It would require a change in the concrete Facade to be able to remove them later though.

// In the concrete Facade class
 
// add a variable
public var loginNotifications:LoginNotifications;
 
...
 
override protected function initializeController():void
{
    super.initializeController();
    loginNotifications = new LoginNotifications( this );
    loginNotifications.register();
}

This way you can later access the LoginNotifications object to remove() them. Personally, I'll probably use this suggestion only when I add commands at runtime, which I don't really do that often.

November 5, 2009 at 10:40 am

Yes, horses for courses.

I tend to register my commands at State Entered and remove them at State Tear down.

again, thanks for the idea.

Tidy up those unsightly Notifications « says:

November 5, 2009 at 11:13 am

[...] GONZALEZ has come up with a really cool way of tidying up those nasty (and so necessary) notification constants. So simple you should have thought of it [...]

Will says:

November 5, 2009 at 2:51 pm

Your point about saving on imports in the Facade is a little odd. What you save on imports in the Facade you make up with imports in your Mediators, Proxies and Commands, right? You'll have to import the LoginNotifications class whenever you need to reference it's constances.

Don't get me wrong, I actually really like the idea of creating locial groups notifications and it certainly outweighs the imports issue. I'll probably try this on my next project. Thanks for sharing!

Tweets that mention Organizing PureMVC Notifications - Almer/Blank Labs -- Topsy.com says:

November 6, 2009 at 11:20 am

[...] This post was mentioned on Twitter by Helio S. Junior and Nolan Butcher, Philip Heyde. Philip Heyde said: RT @H3li0: Organizing PureMVC Notifications – Almer/Blank Labs http://bit.ly/4nZYUf [...]

uberVU - social comments says:

November 6, 2009 at 7:54 pm

Social comments and analytics for this post…

This post was mentioned on Twitter by nebutch: My coworker at Almer/Blank wrote up a good article on PMVC notification organization. http://bit.ly/4EhPue…

Ódýr Vefhýsing says:

November 9, 2009 at 7:33 am

This is a really good idea! Thanks for the heads up and great work!

Regards,
Ódýr Vefhýsing

polykrom says:

November 14, 2009 at 11:19 pm

@hasanotuome

I've use your solution in my new application to define my notifications constants, but there was a problem because the concrete facade wasn't already accessible from my different mediators and proxies while registrating them, the facade returned null, so it was impossible to access my notifications vars.

So, i had to create a getter in my differents mediators and proxies to access the facade like this :

protected function get _facade():LoginModuleFacade
{
if ( multitonKey == null ) throw Error( MULTITON_MSG );
return Facade.getInstance( multitonKey ) as LoginModuleFacade;
}

don't know if it's the right way to do this…

Justin says:

November 16, 2009 at 7:47 am

Bookmarked! Love it.

December 1, 2009 at 12:10 am

@polykrom
if your framework actors do not have references to the facade, then they haven't initialised yet, override the onRegister method an put the code there. This will ensure that the facade is available
cheers

sideDoor says:

January 6, 2010 at 6:25 pm

Great stuff!

@hasanotuome:

Following your approach, how are you accessing the "notes" variable of the ApplicationFacade from within Mediators, Proxies and Commands?

Mediators, Proxies and Commands have the inherited instance-variable facade, a reference to the Facade supertype, but it is typed to IFacade, so, for example, we cannot use facade.notes.login.LOGOUT to get at the constant (notification name).

We can use ApplicationFacade.getInstance().notes.login.LOGOUT, but of course, we have to import our concrete ApplicationFacade class into each actor where needed.

What's your approach here?

Thanks,
jf

matt says:

May 18, 2010 at 5:33 am

Hey Hasan,

Cool addition with the public var notifications in the facade. If this was added to the framework it would remove the need to create concrete facades in many cases. Also the protected variable facade provided by the Notifier class would always allow access to all notifications. Thus also the dynamic adding and removing of commands could be solved that way.

Almer/Blank Labs