tag:robotlegs.tenderapp.com,2009-10-18:/discussions/robotlegs-2/3918-signals-best-practicesRobotlegs: Discussion 2013-07-23T15:43:08Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/278036202013-07-16T19:05:39Z2013-07-16T19:05:39ZSignals Best Practices<div><p>I also had a question about signalCommandMap in RL2</p>
<p>ex:<br>
using Event system :<br>
in AppConfig class we can declare something like this</p>
<p>contextView.view.stage.addEventListener(Event.RESIZE
,handleResize);</p>
<p>function handleResize(ev:Event):void {
dispatcher.dispatchEvent(ev);}</p>
<p>and in some mediator we can add<br>
eventMap.mapListener(eventDispatcher, Event.RESIZE, handleResize,
Event);</p>
<p>but using signalCommanMap , I don't know how to use it since
it's looks like signalCommandMap should map some Signal Class to
command</p></div>khaneron_898tag:robotlegs.tenderapp.com,2009-10-18:Comment/278036202013-07-16T20:52:00Z2013-07-17T01:36:10ZSignals Best Practices<div><p>I think I figured this out. Great question, as I kind of knew
where to start but was fuzzy on this as well... here is the
solution to this that worked for me:</p>
<p>In AppConfig:</p>
<p>`signalCommandMap.map( ResizeSignal ).toCommand( ResizeCommand
); contextView.view.stage.addEventListener( Event.RESIZE,
handleResize );</p>
<p>private function handleResize( e:Event ):void {<br>
//this is the only way I know how to access your Signal instance
from the Config injector.getInstance( ResizeSignal ).dispatch(
contextView.view.stage ); }`</p>
<p>Then your signal class looks like this:</p>
<p>`package { import org.osflash.signals.Signal; import
flash.display.Stage;</p>
<pre>
<code>public class ResizeSignal extends Signal {
public function ResizeSignal() {
//This is the type of class that dispatch passes and is available to inject into your command
super( Stage );
}
}</code>
</pre>
<p>}`</p>
<p>Then finally your command:</p>
<p>`package {</p>
<pre>
<code>import robotlegs.bender.bundles.mvcs.Command;
import flash.display.Stage;
public class ResizeCommand extends Command {
[Inject]
public var stage:Stage; //you can inject this because of your Signal definition
override public function execute():void {
trace( "resize command", stage.stageWidth, stage.stageHeight );
}
}</code>
</pre>
<p>}`</p>
<p>Hope this helps, also would like any experts out there to
validate this solution.</p></div>walpoleatag:robotlegs.tenderapp.com,2009-10-18:Comment/278036202013-07-17T04:03:06Z2013-07-17T06:21:04ZSignals Best Practices<div><p>Thanks for the solution but I think I'll use your Signal Usage 2
in this case since I think I can directly Inject the signal to
mediator and listen to it without need to declare the command , and
btw from example<br>
<a href=
"https://github.com/lidev/robotlegs2-signals-feathers-flickr-example/blob/master/source/AppConfig.as">
https://github.com/lidev/robotlegs2-signals-feathers-flickr-example...</a>
,<br>
I think he use usage 1 for signal that will execute something , and
usage 2 for signal that doesn't need to execute command,<br>
that's make me consider usage 2 is not a bad practice</p></div>khaneron_898tag:robotlegs.tenderapp.com,2009-10-18:Comment/278036202013-07-17T07:10:17Z2013-07-17T07:10:17ZSignals Best Practices<div><p>To clear some things up: it's a good idea to always explicitly
map the signal as a singleton with the injector (usage 2) even when
you map the signal to a command with the signal command map (usage
1).<br>
The signal command map actually does (2) behind the scenes when you
tell it to do (1), if no mapping of the signal with the injector
was found.</p>
<p>However, not mapping the signal explicitly with the injector can
easily lead to bugs.<br>
Let's say you map a signal to a command with the signal command
map. You inject the signal into one mediator, in order to be able
to trigger it, but also into another mediator since it needs to
listen to it.<br>
If you no longer need the command and remove the mapping, the
compiler will not complain, but you'll get run-time errors when the
views of the mediators are added to the stage, since there's no
longer no mapping whatsoever of the signal with the injector.</p>
<p>Also, it's more legible and clear, if you have one central place
where all of the signals are mapped to the injector, regardless of
whether they're mapped with the signal command map or not.</p>
<p>That said, all of the above is one of the reasons why I don't
like to use signals for system-wide messaging. Personally I always
use events system-wide and restrict signals to loose coupled
messaging between two parts: e.g. view to mediator and vice versa,
or parser to service and vice versa.<br>
The major advantage of signals IMO is that you can enforce the
messaging behaviour through an interface, but this only happens
when one class has a direct dependency on the interface of another
class, which is never the case when you use signals
system-wide.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/278036202013-07-17T13:35:05Z2013-07-17T13:35:05ZSignals Best Practices<div><p>Thanks for the insight, that helps a lot!</p></div>walpoleatag:robotlegs.tenderapp.com,2009-10-18:Comment/278036202013-07-17T16:31:12Z2013-07-17T16:31:12ZSignals Best Practices<div><p>Thanks, much more clear now</p></div>khaneron_898