here is the link.

My Email is

nuthell at gmail dot com

The UpdateShoppingCartEvent uses multiple types which map to multiple commands in the controller. All of the other events are one-to-one.

I typically use one-to-one, but when it makes sense I use one-to-multiple.

I use Cairngorm events structured like Flex events all time in my projects. I typically group them around a common value object or a common function. For instance to manage a user I would create a class called UserEvent. Within the UserEvent I would define the following events and also add a property to contain the ‘user’.

public static const addUser:String = ‘ADD_USER’;
public static const updateUser:String = ‘UPDATE_USER’;
public static const deleteUser:String = ‘DELETE_USER’;

public var user:UserVO;

Now I have a single UserEvent that gets registered against three different commands in my FrontController, one for each respective use case in the event. Always have a separate command for each use case, those things should not get combined.

I completely agree about not combining commands. That takes away from the purpose of the command pattern in that each command should represent a single feature in the application.

I suppose you dont have to make it a one to one relationship. Just have one userevent with different types of user events and then in your command execute method run a switch statement to determine which event is being sent and do some logic. Now in that logic area is where will want to use classes as much as possible for reuse, you can also practice your design patterns here as well.

Hope that helps , I started doing this at work recently and now my command folder isn’t as nearly as large.

PS: first time posting on your blog via my iPhone

In regards to the switch statements in your commands, I don’t know about that. The command pattern is meant to represent a single feature of the application. By adding in switch statements, it seems that you are bloating the patterns executable code. I don’t have a problem with the command folder being large, it was this one event for every command thing that I thought was not well thought out.

Thanks for posting.

I dont think you can really get around the 1 to 1 relationship. Even if you do UserEvent.ADD_USER and you also have a UserEvent.DELETE_USER, in the UserEvent class each event will still need seperate commands b/c each one will need to call a different delegate method to run the backend (server) logic.

You could get around the 1 to 1 logic by simply passing the event type to the delegate, which would call lets say a userService, and in that service it would call the correct ADD_USER CFC method to add a User based on the passed in event… likewise you could have a DELETE_USER cfc method that would delete the user if the delete event was passed in as a argument in the CFC… that make sense? It basically makes your delegate really small for Users, and lets you have one User command, one User event and puts all the switching in your CFC to figure out which cfc function to call based on the passed in user event. I thought about doing this once but never did it… figured I could live with a big command folder, one UserEvent, and my delegate just listed all my User Service methods.

Also if you wanted to chain events this is a good post on how to do that:
http://cairngormdocs.org/blog/?p=27

Food for thought

Hows the new job? Ping me sometime lets chat.

public class SomeEvent extends CairngormEvent
{

public static const ACTION_A:String = "ACTION_A";
public static const ACTION_B:String = "ACTION_B";
public static const ACTION_B:String = "ACTION_B";

public function SomeEvent(…

then call it this way
var someEvent:SomeEvent = new SomeEvent( SomeEvent.ACTION_B, …