A Signal is essentially a dispatcher--one that can send your value
object without wrapping it in an Event. So you wouldn't map between
the Signal and the command. You'd map between the VO and the command.
How that mapping is defined is an interesting question. If each VO
class had only one relevant command, you could map VO class to command
class easily. However, if there are multiple commands, how do you
route the VO to the desired one? In Robotlegs' CommandMap, Event.type
is the router. But because Signals are so flexible, they don't impose
a convention like Event.type.
You can still dispatch Event instances through a Signal if you like.
The only issue is that the .target and .currentTarget won't be set;
only EventDispatcher can change those.
I'm glad you brought this up. I don't have answers yet but you've got
me thinking about it. It's probably a puzzle you'll end up solving,
and I'm happy to provide information on how to use Signals.
Robert
signalCommandMap.mapSignal(MySignal, SomeCommand);
I dig commands in that they are such a nice way to encapsulate
business logic.
On Jan 16, 2010, at 5:35 PM, Robert Penner <in...@robertpenner.com>
wrote:
What you've done with Signals is really creative and
thought-provoking, akin to Richard Lord's example:
http://www.richardlord.net/blog/flexcaster-smartysignals
In December, I briefly thought, "What about injecting Signals in my
Robotlegs app?" But I dismissed the idea because I was using normal
Signals and I didn't want to create named injections for them. I
didn't think of using Signal subclasses to solve this, which you did.
This month, I've been using a few Signals to communicate between
Mediators and was wondering if I should make a "SignalBus". It could
be merely a place to store Signals that bridge between application
actors.
But what you're doing is storing Signal subclasses in the Robotlegs
Injector. Then you inject them wherever needed. It's like you exploded
the Context EventDispatcher and its shrapnel is embedded all over the
place (in a good way).
Ok, here's something that may help you with mapping Signals to commands:
public interface ISignal
{
/**
* An optional array of classes defining the types of parameters sent
to listeners.
*/
function get valueClasses():Array;
Man, I wish we had generics.
> function get valueClasses():Array;
Ya, I am passing in the value classes in the super() of my extensions.
It works really well.
I think a SignalCommandMap will be a really simple mechanism. I'm going to flesh it out tomorrow. Good times!