tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/350-maplistener-eventclass-weirdnessRobotlegs: Discussion 2018-10-18T16:35:29Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/87068312011-07-19T08:54:49Z2011-07-19T09:14:29ZMapListener eventClass weirdness<div><p>Hi Tim,</p>
<p>if NumericStepperEvent was a custom event I'd say "Oh, you
forgot to override the clone method!"</p>
<p>But... what I think is this:</p>
<p>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).</p>
<p>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.</p>
<p>Check it out here:</p>
<p><a href=
"http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/spark/components/NumericStepper.html">
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/...</a></p>
<p>This is classic Adobe isn't it? IMO they should be shouting out
"WE CHANGED THE CHANGE EVENT!" in the Spark info!</p>
<p>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.</p>
<p>I hope that helps - if you're <em>not</em> using the new Spark
NumericStepper then I'm wrong and we need to think some more!</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/87068312011-07-19T09:15:50Z2011-07-19T09:15:51ZMapListener eventClass weirdness<div><p>Thanks, Stray!</p>
<p>You are right indeed. I am using the stock Spark NumericStepper,
and had no idea that they changed the event type. Classic.</p>
<p>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?</p>
<p>Thanks again, for the rapid response.</p>
<p>Tim</p></div>Timurtag:robotlegs.tenderapp.com,2009-10-18:Comment/87068312011-07-19T09:27:20Z2011-07-19T09:27:20ZMapListener eventClass weirdness<div><p>Hi Tim,</p>
<p>Excellent, I'm glad that fixed it!</p>
<p>I use signals from views -> mediators, as they avoid me
having to expose the stepper (in your example) at all.</p>
<p>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.</p>
<p>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.</p>
<p>If you check out SignalMediator and SignalMap - this gives you
the same auto-cleanup that you get with events in Robotlegs.</p>
<p><a href=
"https://github.com/Stray/robotlegs-utilities-SignalMediator">https://github.com/Stray/robotlegs-utilities-SignalMediator</a></p>
<p>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.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/87068312011-07-20T08:31:51Z2011-07-20T08:33:20ZMapListener eventClass weirdness<div><p>Thanks, Stray</p>
<p>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:</p>
<p><fx:Declarations></p>
<pre>
<code><local:Signal id="numericStepperClicked" /></code>
</pre>
<p></fx:Declarations></p>
<p><s:NumericStepper click="numericStepperClicked.dispatch()"
/></p>
<p>The question is how would you map this?</p>
<p>Tim</p></div>Timurtag:robotlegs.tenderapp.com,2009-10-18:Comment/87068312011-07-20T08:47:56Z2011-07-20T08:47:56ZMapListener eventClass weirdness<div><p>Hi Tim,</p>
<p>you'd pick it up in your SignalMediator like this:</p>
<pre>
<code>addToSignal(view.numericStepperClicked, handleStepperClick);</code>
</pre>
<p>You need to expose the signal as a property of the view.</p>
<p>On the subject of events vs signals and RSI - the cure of RSI is
dependent on a good code-gen tool, nothing more ;)</p>
<p>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).</p>
<p>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.</p>
<p>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.</p>
<p>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 ;)</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/87068312011-07-20T09:10:34Z2011-07-20T09:10:34ZMapListener eventClass weirdness<div><p>Thanks Stray!</p>
<p>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.</p>
<p>Thanks for your very useful assistance, Stray.</p>
<p>Tim</p></div>Timurtag:robotlegs.tenderapp.com,2009-10-18:Comment/87068312011-07-20T09:44:17Z2011-07-20T09:44:17ZMapListener eventClass weirdness<div><p>Hi Tim,</p>
<p>it doesn't sound like you're going about it wrongly.</p>
<p>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...</p>
<p>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).</p>
<p>The proportion of interesting actions / responses that you
implement through events could be seen as a measure of de-coupling
of your app.</p>
<p>Robotlegs gives you lower coupling, and you <em>know</em> this
because you have to make a lot more events!</p>
<p>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.</p>
<p>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.</p>
<p>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!</p>
<p>Stray</p></div>Stray