Home → Problems →

mapSignalClass auto add Signal listener

• Edit

simon

08 Feb, 2010 01:08 PM

Hi,

As with most people on this board I would like to say thanks to all contributors for this framework, I really do think its the shiznit!

I have been playing over the weekend with Signals and RL and had an idea that I thought I would put forward but am aware I may have (a) missed something potentially or (b) it may be plain wrong to suggest.

Here's the scenario, I have a Signal that I want to be bound to a Command:

signalCommandMap.mapSignalClass( CustomSignal, CustomSignalHandlerCommand, true );

I would have to add the Signal's listener to CustomSignalHandlerCommand, it is here where I was trying to think of the best place to do this. My instinct was to place the logic in the CustomSignalHandlerCommand execute() override:

[Inject] public var somethingUpdated:CustomSignal;


override public function execute():void
{

   somethingUpdated.add( onSomethingUpdated );

}

protected function onSomethingUpdated( val:Object ):void
{

  // Something update

}

The only problem with this is that the listener is not assigned until the Command is executed which is on dispatch of the Signal. I overcome this by having a startup Signal that I map the CustomSignalHandlerCommand to which then runs the execute() override on startup?

If I have not got the logic wrong and if this is a valid approach to take then is it feasible to suggest when mapSignalClass() is used that the commandClass is auto assigns the injection aspect building a handler? Or is that just plain stuuuuupid.

I did look at using a Class that extends Actor (say a Proxy for instance) to respond to the Signal dispatch, I like the idea of lazy instantiation, but I would initially instantiate this Class when I dispatched the Signal so the same scenario occurs, how would I assign the Signal Listener?

Cheers,

Simon

1. 1 Posted by George M on 08 Feb, 2010 02:43 PM

   

   I am having the same issue.
   I can't seem to figure out how to pick up arguments that were passed to my “CustomSignal” in my “CustomSignalHandlerCommand”.
   My approach was the same as Simon’s above but in my example the “listener” is not triggered.
   I and am also starting to feel that either my approach is wrong, or something has been overlooked.

   In brief, how we pick up on the Signal values in Commands?

   Thanks

   George

   • Edit

2. 2 Posted by Stray on 08 Feb, 2010 03:10 PM

   

   Possibly a dumb question but did you check out the unit tests Joel included in his source? Dig into his code in the support package, for the 2 and 3 property commands.

   Those were a big help to me.

   My understanding is based on having used this a little, and I could be way off base, but here's what's working for me:

   If you've got values in your signal then you can inject them in the command and the injection mapping of those value objects is handled by the command map. They don't even have to be custom types, provided they're unique in the command. They get mapped, injected and unmapped on the fly. Very neat.

   I think a constraint is that you can't have more than one value of the same type in your signal arguments / injected properties. You also can't have previously mapped those types in the injector.

   If you did need to have more than one value of the same type, you could use a typed array / Vector. My preference is for custom wrapper classes.

   Joel may know of a better way :)

   so - if it's someSignal.dispatch(someNumber, someString)

   then in your command you need

   [Inject]
   public var someNumber:Number;

   [Inject]
   public var someString:String;

   override public function execute()
   {

   // do stuff using someNumber and someString...

   }

   • Edit

3. 3 Posted by simon on 08 Feb, 2010 03:21 PM

   

   Stray thanks for the reply, not a dumb question at all and damned if I looked at the unit tests [slaps forehead], gonna dig now, cheers!

   • Edit

4. 4 Posted by Stray on 08 Feb, 2010 03:38 PM

   

   No worries, it's also worth checking out the 'routeSignalToCommand' function in SignalCommandMap:

   http://github.com/Stray/signals-extensions-CommandSignal/blob/master/src/org/robotlegs/base/SignalCommandMap.as

   basically the process seems to be:

   - mapping the signal->command automatically creates a listener for the signal's dispatch, which will then trigger that routeSignalToCommand function.

   - when the signal dispatches, the SignalCommandMap:

   1) Iterates through the signal's dispatch arguments, creating mappings for those types/ values
   2) Asks the injector to instantiate the command, fulfiling its injections using those mappings that just got created
   3) Unmaps all those signal dispatch arguments
   4) runs the .execute() on the command
   5) if it's oneshot, removes the signal->command mapping.

   It's a pretty neat piece of work. Thx Joel & RP.

   • Edit

5. 5 Posted by George M on 08 Feb, 2010 03:55 PM

   

   Stray, thanks for pointing these out :o)

   (it is eagerness and deadlines that makes us overlook them)

   I have it working nicely now!

   Indeed props go out to Mr Hooks & Mr Penner, and to you for pointing the way

   • Edit

6. Support Staff 6 Posted by Joel Hooks on 08 Feb, 2010 04:24 PM

   

   Stray is right, the values are injected. Right now, the injection is a little odd I think, but this is do to the limitations on the IInjector interface (and the reason for the discussions regarding adding a couple of methods to it).

   I don't think the Signal will get injected either way. The Signal triggers the command, the command doesn't trigger the signal. Since the Signal itself doesn't hold any properties, it wouldn't be very useful.

   She is also correct in that the unit tests are the only documentation available right now :> - that will change when I can finally come up for air!

   • Edit

7. Joel Hooks closed this discussion on 08 Feb, 2010 04:24 PM.