tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/364-mediator-onregister-vs-dependency-injection-of-signalsRobotlegs: Discussion 2018-10-18T16:35:31Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/96702122011-08-31T19:25:35Z2011-08-31T19:25:35ZMediator onRegister() vs. Dependency Injection of Signals<div><p>I am injecting a signal into a view:</p>
<p><code>[Inject] public var
playbookInteractionCompletedSignal:PlaybookInteractionCompletedSignal;</code></p>
<p>That signal is mapped to the injector, and the view's mediator
is mapped to the view, all in the context::</p>
<p>
<code>injector.mapSingleton(PlaybookInteractionCompletedSignal);'</code></p>
<p><code>mediatorMap.mapView(PlaybookView,
PlaybookViewMediator);</code></p>
<p>The signal is injected into the view's mediator
(PlaybookViewMediator), and the signal listened to in the
onRegister method of the mediator. The view being listened to is
also injected:</p>
<p><code>[Inject] public var
playbookInteractionCompletedSignal:PlaybookInteractionCompletedSignal;</code></p>
<p><code>[Inject] public var playbookView:PlaybookView;</code></p>
<p><code>override public function onRegister():void</code>
<code>{</code></p>
<pre>
<code> `playbookView.playbookInteractionCompletedSignal.add(onPlaybookInteractionCompleted);`</code>
</pre>
<p><code>}</code></p>
<p>The problem is that I am getting a runtime error in the
PlaybookViewMediator - that line above in the onRegister method
where I add the handler to the signal, and I can't figure out
why.</p>
<p>Any help is greatly appreciated.</p>
<p>Jason Merrill</p></div>jason.merrilltag:robotlegs.tenderapp.com,2009-10-18:Comment/96702122011-08-31T19:55:22Z2011-08-31T19:55:22ZMediator onRegister() vs. Dependency Injection of Signals<div><p>Hi Jason,</p>
<p>Robotlegs doesn't inject into views unless you use the viewMap -
and the viewMap and mediatorMap aren't really intended to be used
together - it's generally a 'one or other' approach.</p>
<p>Why are you injecting the signal into the view using [Inject]?
Options include creating the signal as a property of the view, or
passing it manually from the mediator into the view itself. Either
way, the approach you have at the moment looks like too much
reliance on the injector to me - there are much simpler ways to get
the job done.</p>
<p>Also, you'll need to use SignalMediator and SignalMap to avoid
memory leaks when using signals in mediators - check them out on
github.</p>
<p>I don't think you're far from a solution - just don't rely on
the injector to provide that signal to the view and you'll be
golden.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/96702122011-09-01T01:45:36Z2011-09-01T01:45:36ZMediator onRegister() vs. Dependency Injection of Signals<div><p>Thanks Stray. Everything I was doing I thought was the way I
should be doing it, so I'll try your suggestions. Thanks so
much!</p></div>jason.merrilltag:robotlegs.tenderapp.com,2009-10-18:Comment/96702122011-09-01T18:16:08Z2011-09-01T18:16:08ZMediator onRegister() vs. Dependency Injection of Signals<div><p>Ok - got it working. Yeah, I was over-injecting was the problem
(I was already using SignalMediator - also SignalCommandMap - but
what is SignalMap?).</p>
<p>So it's working great now, thanks!</p></div>jason.merrilltag:robotlegs.tenderapp.com,2009-10-18:Comment/96702122011-09-01T18:22:18Z2011-09-01T18:22:18ZMediator onRegister() vs. Dependency Injection of Signals<div><p>Ah! cool :)</p>
<p>SignalMap is used internally by SignalMediator - so as long as
you use "addToSignal(... )" you're golden. Basically if you add
your handlers directly then you need to clean up manually when the
mediator is destroyed (when the view leaves the stage). If you use
SignalMap (through SignalMediator) then you get automatic clean
up.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/96702122011-09-01T19:01:15Z2011-09-01T19:01:15ZMediator onRegister() vs. Dependency Injection of Signals<div><p>Oh cool - I am using addToSignal now in my SignalMediator and it
works great - thanks! That's awesome.</p></div>jason.merrill