tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/609-joel-hooks-signalcommandmap-vs-regular-signalsRobotlegs: Discussion 2018-10-18T16:35:29Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/87069312011-07-21T15:10:31Z2011-07-21T15:10:31ZJoel Hooks' SignalCommandMap vs Regular Signals<div><p>Sorry for the delay - your message was stuck in spam (oops).</p>
<p>I'd say forget methods vs classes and think in terms of
responsibilities and ownership.</p>
<p>If a timerModel dispatches a tick signal, this signal is
probably a property of that timerModel. It belongs with the
timer.</p>
<p>On the other hand a 'quit' signal doesn't really 'belong' to any
one class in most applications (unless you have a giant state
machine for this but ignore that possibility for now). So it sits
better for me as a stand-alone.</p>
<p>I think John's 'signal' is still a model - it just uses
signals.</p>
<p>I like to mix it up and I generally use all 3 approaches:
injected strong-typed signals, signal-properties of objects and
events. They each have pros and cons and I like to pick the most
appropriate one for each task.</p>
<p>Signals are probably too new for there to be a real gospel on
how best to use them - even Robert is switching back and forth on
whether he likes signal buses and so on or not.</p>
<p>As for RL2 - we plan to build the feature set with events first
and then provide signals driven and events+signals driven
alternatives. Robotlegs 2 is more of a "This - plus - this - plus -
this" approach (ie you specify which maps you want to include) so
it'll be much easier to implement signal and mixed alternatives to
the core maps.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/87069312011-07-21T18:57:38Z2011-07-21T18:57:38ZJoel Hooks' SignalCommandMap vs Regular Signals<div><p>@Dave,</p>
<p>Since I'm studying the same aspects of RL & Signals-Event
integration, my take on it is that John's excellent tutorial
demonstrates the usage of Signals outside of any framework
(Robotlegs) per se, whereas Joel's signalCommandMap tutorial
demonstrates how to map signals to RL commands, and Stray's
SignalMediator extends RL's Mediator and allows one to use
SignalMap to map signals to handlers alongside an eventMap that
does the same for events. That's the way I see it at least.</p>
<p>@Stray,</p>
<blockquote>
<p>I like to mix it up and I generally use all 3 approaches:
injected strong-typed signals, signal-properties of objects and
events. They each have pros and cons and I like to pick the most
appropriate one for each task.</p>
</blockquote>
<p>Could you please give us an example of how you'd use each of the
three. I think a concrete example would help cement these concepts
for many, not necessarily as a real gospel, as you say, but rather,
as a rationalized approach.</p>
<p>Thanks again,</p>
<p>Tim</p></div>Timurtag:robotlegs.tenderapp.com,2009-10-18:Comment/87069312011-07-21T19:25:53Z2011-07-21T19:25:53ZJoel Hooks' SignalCommandMap vs Regular Signals<div><p>Hi Tim,</p>
<p>ok - so:</p>
<p>I use injected signals to create a one-to-one channel between a
mediator and a command, for example if there are multiple instances
of the same view on stage, and the user has clicked 'next' in one
of them, so that the next set of data comes specifically to this
view.</p>
<p>These signals are not a property of any object - they stand
alone.</p>
<p>I use property-signals from my views to my mediators if the view
is complex. So - a log in panel might expose signals for submit,
quit, forgotPassword.</p>
<p>I use events for pretty much everything else (though I might
well use signals more and more in future).</p>
<p>Does that help?</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/87069312011-07-21T21:57:25Z2011-07-21T21:57:25ZJoel Hooks' SignalCommandMap vs Regular Signals<div><p>Hi Stray,</p>
<p>So in the first example, you inject a signal into your command,
instead of mapping the signal in your mediator to your command (the
one to one channel)? I'm not sure if that's it.</p>
<blockquote>
<p>These signals are not a property of any object - they stand
alone.</p>
</blockquote>
<p>Where do they get instantiated, then?</p>
<blockquote>
<p>I use property-signals from my views to my mediators if the view
is complex. So - a log in panel might expose signals for submit,
quit, forgotPassword.</p>
</blockquote>
<p>OK. I do something along those lines (I think):</p>
<pre>
<code><s:Button id="save_btn" click="saveButtonClickedSignal.dispatch()" /></code>
</pre>
<p>Then in the view's mediator I can listen for the
saveButtonClickedSignal.</p>
<blockquote>
<p>I use events for pretty much everything else (though I might
well use signals more and more in future).</p>
</blockquote>
<p>OK, but if Signals are more performant than Events, require less
code to create than events, and bubbling notwithstanding, then the
only advantage I have found discussed so far is the fact that one
Event could have multiple String Constants doing the job of several
signals (if I understood it correctly, that is). I really like the
visual compactness of Signals. Once you start using them, they
could become second nature rather quickly.</p>
<p>Thanks for you illustrations and explanations, Stray!</p>
<p>Tim</p></div>Timurtag:robotlegs.tenderapp.com,2009-10-18:Comment/87069312011-07-22T08:06:34Z2011-07-22T08:06:34ZJoel Hooks' SignalCommandMap vs Regular Signals<div><p>Hi Tim,</p>
<p>They are "Signaltons" - ie Singleton Signals - and the
SignalCommandMap takes care of the mapping on the injector. They
will be instantiated the first time something requires them to be
injected.</p>
<p>There are some pragmatic reasons why I've continue to use Events
(as well as Signals):</p>
<p>1) The Signals library is still in beta and until it hits 1.0
the API is subject to change, as well as the composition of
interfaces.</p>
<p>2) I'm integrating parts of code that are events based
(utilities etc)</p>
<p>3) For some things - for example logging - I think events are a
better fit with my mental model of what's going on.</p>
<p>4) My app is modular, and my modules don't share injections or
app domains. It's much easier to relay events between modules than
it is to re-wire signals - you end up having to create signal buses
so that you can pass a smaller number of objects as your objects
have to 'belong' somewhere. I call these 'channels'. It works and
has great use cases but in my mind it defeats much of what is good
about signals and in that form it doesn't really give you any
advantage over events (milliseconds are irrelevant in my app).</p>
<p>5) Adding listeners to signals is order-of-operations dependent.
Event listeners are much more neutral about order-of-ops. Which
again makes it easier to work with Events in a situation where you
have multiple modules being loaded in various combinations over
time.</p>
<p>6) Robotlegs gives you some degree of type safety for events -
almost on a par with Signals except that you can still dispatch
silly things, and you don't get a useful error message like you do
with signals. I use TDD so I am pretty sure my code isn't
dispatching silly things.</p>
<p>However - don't take that to mean that I don't love Signals. I
love both - they are quite different in what they offer though.</p>
<p>I even use the two in combination - I sometimes create
RequestEvents that contain a response signal for the command to
reply on.</p>
<p>I hope that make sense :) I think it's odd that so many people
have gone straight for the "I'm a signals person" or "I'm an events
person" dichotomy - to me it feels like saying "I'm a keyboard
person" or "I'm a mouse person". You might have a preference for
one or the other, but the best approach is to combine the two!</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/87069312011-07-23T04:42:51Z2011-07-23T04:42:52ZJoel Hooks' SignalCommandMap vs Regular Signals<div><p><a href=
"https://m.google.com/app/plus/mp/451/#~loop:backv=notifications&aid=z13cf5ub5n3vfn4cw23wv3abfu2aed0d3&type=1&fr=1&view=activity">
https://m.google.com/app/plus/mp/451/#~loop:backv=notifications&amp...</a></p>
<p>This is an interesting discussion about where I'm at with the
SCM</p></div>Joeltag:robotlegs.tenderapp.com,2009-10-18:Comment/87069312011-07-24T05:19:25Z2011-07-24T05:19:25ZJoel Hooks' SignalCommandMap vs Regular Signals<div><p>Hi all, I'm sorry for responding so late after the fact.</p>
<p>@Stray, thanks very much for phrasing it in terms of
responsibilities - that clears things up very much. Also Timur,
after looking at it again it does seem to be the way you said -
John's tutorial was not as a part of Robotlegs, while the
SignalCommands and SignalContext's obviously are.</p>
<p>I think I'm going to use all three methods, signals,
signalCommands and events, similar to Stray. The key to
maintainable code is consistency, so I'll use responsibilities to
decide which kind of signals to be using in my app, and leave
things as events at the fringe of the app, where I communicate
using flash events for services and the like.</p>
<p>Or at least that's where I was before reading Joel's link. I've
other things to do so I can push signals back a bit while I
reconsider using them. Since it's a relatively big project the
"cognitive overhead" described by Joel could become a real
issue.</p>
<p>Thank you everyone for the advice. I kind of assumed signals
were the way to go simply because I'm wary of the string matching
used by events but since you can specify the event class in the
Context that's not as huge a problem as it could be.</p></div>Davetag:robotlegs.tenderapp.com,2009-10-18:Comment/87069312011-07-26T21:20:46Z2011-07-26T21:20:46ZJoel Hooks' SignalCommandMap vs Regular Signals<div><p>Hi Dave,</p>
<p>Not that I'd want you to switch your <a href=
"http://polygeek.com/4369_flash-builder_how-not-to-convince-someone-to-swich-ides">
IDE</a>, but John Lindquist has created a very useful <a href=
"https://github.com/johnlindquist/open-source-plugins">plugin</a>
for Intellij IDEA that, I think will help reduce some of the mental
burden associated with following the breadcrumb trail of
mediators/views, commandMaps/events, and more. Like Stray said, it
really is a case of using code-gen as much as possible and have
tools that help with the wiring.</p>
<p>Tim</p></div>Timur