Home → Problems →

MapListener eventClass weirdness

• Edit

Timur

19 Jul, 2011 07:38 AM

Hi all,

I'm new to RL and I'm taking it for a spin to see what's it like, so my question assumes no prior knowledge. I have created a simple view component containing a NumericStepper, stepper_a. In the view's Mediator onRegister function I map the the stepper's event to a handler stepperChangedHandler.

eventMap.mapListener(view.stepper_a, NumericStepperEvent.CHANGE, stepperChangedHandler);

and below in the same file I have the handler:

protected function stepperChangedHandler(event:Event):void
{
    //do whatever
}

Everything's honkey dory, but if I add the optional eventClass parameter:

eventMap.mapListener(view.stepper_a, NumericStepperEvent.CHANGE, stepperChangedHandler, NumericStepperEvent);

the event never reaches the handler. As a matter of fact the handler does not run.
Am I missing an obvious step here or is something slightly wonky here?

Thanks,

Tim

1. 1 Posted by Stray on 19 Jul, 2011 08:54 AM

   

   Hi Tim,

   if NumericStepperEvent was a custom event I'd say "Oh, you forgot to override the clone method!"

   But... what I think is this:

   You're using the Spark component of NumericStepper, not the original mx.controls version? The 'CHANGE' event in the new Spark NumericStepper is actually a normal Event.CHANGE (it is defined by the Spinner class).

   Of course the string constant for 'CHANGE' is the same for either event - which is why it was firing until you specified the event class.

   Check it out here:
    
   http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/spark/components/NumericStepper.html

   This is classic Adobe isn't it? IMO they should be shouting out "WE CHANGED THE CHANGE EVENT!" in the Spark info!

   So - your choice is to either specify the class as Event when you mapListener or not - it's the default value for that parameter, but personally I prefer to always define that eventClass parameter just because it's the habit I'm in.

   I hope that helps - if you're *not* using the new Spark NumericStepper then I'm wrong and we need to think some more!

   Stray

   • Edit

2. 2 Posted by Timur on 19 Jul, 2011 09:15 AM

   

   Thanks, Stray!

   You are right indeed. I am using the stock Spark NumericStepper, and had no idea that they changed the event type. Classic.

   I noticed that many on this forum prefer Signals to Events. Are they 100% interchangeable? Meaning, can I replace Flash Events entirely with Signals, or are there situations where Events are still preferred?

   Thanks again, for the rapid response.

   Tim

   • Edit

3. 3 Posted by Stray on 19 Jul, 2011 09:27 AM

   

   Hi Tim,

   Excellent, I'm glad that fixed it!

   I use signals from views -> mediators, as they avoid me having to expose the stepper (in your example) at all.

   Personally I still see that both approaches have advantages, and I like to use them in different roles. But people really seem to have different views on where each is better / worse, and it's as much about work flow as anything, so you'd probably need to try them and make your own assessment.

   Your stepper itself would still emit the event obviously, but you'd catch it internally and then dispatch the number it changed to in a signal which the view's mediator would catch.

   If you check out SignalMediator and SignalMap - this gives you the same auto-cleanup that you get with events in Robotlegs.

   https://github.com/Stray/robotlegs-utilities-SignalMediator

   What I'd say is that if you're not familiar with Signals already, learn one thing at a time - it's fewer "wh?" moments to work through. And then add Signals afterwards. They're not tricky but you can waste a lot of energy if you're not sure what the source of your problem is and it could be in either of 2 new tools.

   Stray

   • Edit

4. Timur closed this discussion on 19 Jul, 2011 06:05 PM.

5. Timur re-opened this discussion on 20 Jul, 2011 08:31 AM

6. 4 Posted by Timur on 20 Jul, 2011 08:31 AM

   

   Thanks, Stray

   As I read more about Robotlegs, Signals is not far behind. It seems that one complements the other. The ability to reduce custom event creation, which is required as a de facto communication method between view and mediator, almost mandates the use of Signals to avoid RSI, it seems. So in theory, I could even place Signals in MXML view:

   <fx:Declarations>
   <local:Signal id="numericStepperClicked" />
   </fx:Declarations>

   <s:NumericStepper click="numericStepperClicked.dispatch()" />

   The question is how would you map this?

   Tim

   • Edit

7. 5 Posted by Stray on 20 Jul, 2011 08:47 AM

   

   Hi Tim,

   you'd pick it up in your SignalMediator like this:

   addToSignal(view.numericStepperClicked, handleStepperClick);

   You need to expose the signal as a property of the view.

   On the subject of events vs signals and RSI - the cure of RSI is dependent on a good code-gen tool, nothing more ;)

   If you choose to use Signals for all your messaging you will most likely end up with more custom classes, not less. You can use vanilla signals between the view and the mediator, but for injecting them around the place they'll need to be strongly typed (so that you have something to inject against).

   A single event class can have multiple types (designated by different string constants). Every signal is unique. Generally I'd expect to have two or three times as many signal classes as event classes when I make the switch.

   Not that this is a bad thing - I'm all for strong typing. But more/less code is the wrong lever to be trying to pull on.

   What IDE do you use? Creating a custom event (or a custom signal) should be so easy that the process never figures in your decision making. Your hands / wrists should be leaving the decision making to your brain ;)

   Stray

   • Edit

8. 6 Posted by Timur on 20 Jul, 2011 09:10 AM

   

   Thanks Stray!

   As far as the IDE, I alternate between FB and IDEA. IDEA is already loaded with templates for most Robotlegs actors. So I do use code-gen when I can. Since I am new to RL, I'm a little overwhelmed by the sheer number of events that need to be created (with or without code-gen). For every view there needs to be an event that will be picked up by the view's mediator. Then a framework event needs to be created by the mediator for every handler that it picks up from the view event. (Please correct me if I'm going about this in a wrong manner.) So it's as though every view needs to have two events fired to reach a destination. I just have to get used to that, that's all. But of course, any other code-gen tools or any helpers are very useful.

   Thanks for your very useful assistance, Stray.

   Tim

   • Edit

9. 7 Posted by Stray on 20 Jul, 2011 09:44 AM

   

   Hi Tim,

   it doesn't sound like you're going about it wrongly.

   If you think of your view events as "actions, aka interesting things that the user can do to the interface", and your app events as "responses to these actions, and responses to the consequences of these actions" then there should be exactly as many events as there are unique interesting actions and unique interesting responses...

   You can only reduce that number by coupling together parts of your application which trigger and are interested in those events, or by treating unique actions and responses as if they are in some way generic - and using state (a model for example) to capture the uniqueness instead (which is usually messy).

   The proportion of interesting actions / responses that you implement through events could be seen as a measure of de-coupling of your app.

   Robotlegs gives you lower coupling, and you *know* this because you have to make a lot more events!

   If we see that the events are really 'messages', we can start to replace some of those events with signals - we still have the same number of messages, we're just changing how we implement them.

   You also have some choices about how you break down your view/mediator relationships. If you go for more granular mediators (for example, mediating a quit button) then you don't need any custom view events (or signals) because you can listen direct to the view for 'click'. The mediator-view one-to-one relationship ensures the 'uniqueness' of the click event for you.

   You only need to create custom events for composite views - and that's where I definitely think that signals are a great (and more performant) option!

   Stray

   • Edit

10. Timur closed this discussion on 21 Jul, 2011 05:06 AM.