Almer/Blank Labs

Over the weekend I updated both the ZamfBrowser application and the ZendAmfServiceBrowser class that gives the ZamfBrowser information about your ZendAMF services set up.   …read more…

A common practice amongst PureMVC developers when creating PureMVC Mediator implementations is the “view getter”, a getter method that returns the instance of the view object that the Mediator is coupled with. As an example I will use an imaginary media player with a playlist. …read more…

Just posted an update to ZamfBrowser.  ZamfBrowser can now generate code for use in either Flash or Flex based projects.   …read more…

ZamfBrowser is a ZendAMF Service Browser, like the AMFPHP Service Browser, which lets a developer unit test ZendAMF services.  I posted this project today for download on RIAForge at http://zamfbrowser.riaforge.com.   …read more…

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. =)