AS3 Robot legs and Signals - Using Signals, Quite verbose, any alternatives?

Question

Im using RobotLegs and Signals for my application. This is my first time using Robotlegs, and Im using Joel Hooks Signal Command Map example here

I've noticed that it seems quite verbose in contrast to events. For every Signal I have to create a new class, whereas with events I would group event types into one class.

I like how visually and instantly descriptive this is.. just browsing a signals package will reveal all app communications. Although it seems quite verbose to me.

Are other people using this, Is the way I'm using signals like this correct, or have people found a way around this verboseness?

Cheers

Answer 1

It's the correct way though. The major advantage of signals is you can include them in your interface definitions, but obviously you'll end up with a big pile of signals.

In general I use signals only for my view->mediator and service->command communication (1-to-1). For system wide notifications I use events (n-to-n). It makes the number of signals a bit more manageable. But it's a matter of preference obviously.

Using a good IDE and/or a templating system alleviates a lot of the "pain" of having to create the various signals.

Answer 2

You do not have to make a new signal class for Command maps, its just good practice. You could just give the "dataType" class a type property - and do a switch on that. But that would be messy for commands. But note, Commands are basically for triggering application wide actions.

Not all signals trigger application wide actions.

For instance, if you are responding to a heap of events from a single View. I suggest making a Signal class for related "view events" (e.g. MyButtonSignal for MyButtonView) and give it a type property.

A typical signal of mine will look like:

package {
    public class MyButtonSignal extends Signal {
        public static const CLICK:String = 'myButtonClick';
        public static const OVER:String = 'myButtonOver';

        public function MyButtonSignal() {
             super(String, Object);
        }
    }
}

Dispatch like so

myButtonSignal.dispatch(MyButtonSignal.CLICK, {name:'exit'});

Listen as normal:

myButtonSignal.add(doMyButtonSignal);

Handle signal like so:

    protected function doMyButtonSignal(type:String, params:Object):void {
        switch(type) {
            case MyButtonSignal.CLICK: trace('click', params.name);         
                break;


            case MyButtonSignal.OVER: trace('OVER', params.name);           
                break;
        }
    }

Occasionally its useful to give the data variable its own data class.

So everytime you realise "Aw shit, I need to react to another event", you simple go to the Signal and add a new static const to represent the event. Much like you (probably?) did when using Event objects.

Answer 3

For every Signal I have to create a new class, whereas with events I would group event types into one class.

Instead of doing that you could just use the signal as a property… something like:

public var myCustomSignal:Signal = new Signal(String,String);

You can think of a signal as a property of your object/interface.

In Joel's example he's using signals to denote system level events and is mapping them with the robotlegs SignalMap which maps signals by type. Because they are mapped by type you need to create a unique type for each system level signal.