In the 1-to-1 mapping approach, the only way I see how one can lower the number of Notification classes being used (instead of extending meaninglessly to support different Notification class name signatures) is letting the command process some given “type” variable of that notification (via switch-case), and handle multiple command cases tied to a single notification class within the command itself. This could very well mean lesser Command/Event classes being used, but a longer command class code because it handles multiple type cases, moving closer to a 1-shot controller somewhat. It can be a bit harder to manage when dealing with undoable commands which might contain undoable information more specific to a particular action gesture, or more testable commands which should be written as a sole class handling 1 specific case only.

Another way (for a Robotlegs app i’m doing which handles many commands/gestures) is to simply let each given public static const string in an Event class be marked with some [CommandGesture] meta-data, whose resolved string value must match the given command name (via some logical type-matching convention). When mapping a Command class, the assosiated event/notification class is being inspected for a matching CommandGesture string in the event, and if no matching trigger is found based on the string-matching convention, it throws an error. This does force the developer to create proper events strings that would be resolved to auto-mapped command class names, but at least, the app throws out warnings/errors if the mapping fails. As far as configuration goes, the only thing required is to simply list out all the commands to be auto-wired, since the rest is handled by convention.

I totally agree that the compiler is the best tool for spotting errors! Thats my whole aim in increasing type safety.

The problem I want to avoid (like the plague) is when strongly typed code is in fact not type safe.

The classic example is events, here is some strongly typed code (the compiler loves it ) that is far from type safe

myObject.addEventListener(Event.Close, function(event:Event):void{});

// later on

myObject.addEventListener(MyEvent.Close, function(event:MyEvent):void{});

Since both MyEvent.CLOSE and Event.CLOSE are equal to “close” both listeners will be triggered by both events, and the strongly typed code will throw a runtime type error.

So strong typing is very very valuable, but it can also cause unfounded confidence in non-strict code.

With my approach there is a clear limitation! The developer may misspell Execute, and the compiler will not be there to help them out. But there is also a clear advantage, there is no possibility of the developer triggering a command with an incorrect type that consequently throws a runtime error.

With the approach of injecting the notification via a property and mapping the command to the notification

> commandMap.addCommand(MakeHay, MakeHayCommand);

We remove the problem of the compiler not informing us that the execute method is misspelled, but I do not believe we create a more type safe situation, we just return to adding a mapping step.

I personally would rather (since there is no silver bullet which achieves type safety and strong typing, that I can yet see) use the approach that keeps the mapping in context, i.e. the mapping is done in the object that takes action on the notification rather than in a removed mapping step.
It also removes some duplication, since creating a command that depends on a notification via an inject does not definitively map that command to that notifications type, so we then have to map it (two places we have to describe what type the command is expecting). In the approach I am describing the dependency and the mapping are one and the same, so never out of date or in disagreement.

Phew, that got me thinking

cheers
Sammy

commandMap.addCommand(MakeHay, MakeHayCommand);

Your metadata approach requires its own kind of developer discipline (put a MakeHay parameter in the method and mark with [Execute]). But the compiler doesn’t complain if it isn’t done correctly.

> See how I do not have to tell the command map that the MakeHay notification triggers this command!

Right, do you mean you’ve avoided doing something like this?

commandMap.addCommand(MakeHay, MakeHayCommand);

Basically you’ve moved the MakeHay mapping from one place to another. In order to do that, you defined a new metadata tag, parsed it, and created an inability to use a command interface. Personally, I am reluctant to create new metadata when there’s a simple ActionScript equivalent, which is strongly typed and easier to debug.

> My other main reason, was that it is felt familiar to most other command patterns I’ve worked with in the past

When I Google around and look at Wikipedia, I see predominantly execute().

There are a couple of reason for having the notification as a parameter of the [Execute] method. The most important is that it is used by dawn to automatically map the command class to the notification that triggers it. Adding a command in dawn looks like this

commandMap.addCommand(MayHayCommand);

See how I do not have to tell the command map that the MakeHay notification triggers this command! dawn performs reflection on the command, finds the type of the executes parameter and maps (via dawns notification bus) the command to that type. This not only removes a configuration step, it retains the type safety of the command.

If I was to inject the notification like a dependency of the command, how would dawn know which property to map the command to? (since notifications do not have to implement an interface or extend a type, they are just like any other object).

I also think it clearly distinguishes between something that is a dependency of the command and a payload that it can work on.

My other main reason, was that it is felt familiar to most other command patterns I’ve worked with in the past (with the exception of robotlegs?).

thanks a lot
Sammy

class MakeHayCommand{
[Inject] public var barn:Barn;
[Inject] public var note:MakeHay;

[Execute] public function execute():void{
barn.makeHay(note.howMuchHay);
}
}

I just wondered if you’ve ever taken a look at the parsley framework before?
http://www.spicefactory.org/parsley/docs/2.1/manual/

A lot of people are hyping this as the next big thing (especially as it seems to be part of the new caringorm spec), however I initially rejected it because of the heavy footprint for pure as projects.

Have you any plans to move the framework in this direction at all?

Thanks again, this looks very promising.