tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/199-dependency-across-mediatorsRobotlegs: Discussion 2018-10-18T16:35:13Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/20295552010-06-22T10:30:02Z2010-06-22T10:30:02ZDependency across mediators<div><p>Hi Kyma,</p>
<p>your mediators really shouldn't have any clues about each other,
so I'm wondering whether there's something gone awry in your
understanding of how to use the framework?</p>
<p>The mediators will both have a reference to the shared
eventDispatcher. This provides a channel for events passing between
mediators. If you dispatch and listen for events on this
eventDispatcher then you'll find that they can work together,
entirely decoupled.</p>
<p>So - if this is what you're doing:</p>
<p>public class FirstMediator {</p>
<pre>
<code>[Inject]
public var secondMediator:SecondMediator ...</code>
</pre>
<p>then it would be a good idea to take a look at some
examples.</p>
<p>The correct way to wire mediators together is like this:</p>
<p>// In mediator 1 when something happens that other mediators
might care about</p>
<pre>
<code>dispatch( new SomethingEvent(SomethingEvent.SOMETHING_HAPPENED));</code>
</pre>
<p>// In mediator 2 in the onRegister function:</p>
<pre>
<code>onRegister():void
{
eventMap.mapListener(eventDispatcher, SomethingEvent.SOMETHING_HAPPENED, somethingHappenedHandler);
}</code>
</pre>
<p>This way the mediators can listen for each other's events,
without being injected into each other.</p>
<p>The purpose of a mediator is purely to be a way to hook a
specific view into your framework without having to put framework
code in the view. Mediators should dispatch events on the shared
dispatcher when something happens to their own view, and should
update their view (via the view API) when events arrive on the
framework eventDispatcher that are important to that view.</p>
<p>Generally you shouldn't be injecting anything extra into your
mediators - only the view. If you're using signals then you might
be injecting some signals as well, but don't inject anything beyond
that unless you're deliberately breaking the protocol in way that
you understand the consequences of :)</p>
<p>Apologies if I've misunderstood what you're describing.</p>
<p>Generally Commands are for working with models and services
(Actors). It's rare that a Command is the best approach for working
with views / mediators.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/20295552010-06-22T10:38:28Z2010-06-22T10:38:30ZDependency across mediators<div><p>Thanks for the response. You're right, I had misunderstood the
meaning of the eventDispatcher property. I had thought it was
looking for an instance of the object dispatching the event. What
is the eventDispatcher then?</p></div>Kymatag:robotlegs.tenderapp.com,2009-10-18:Comment/20295552010-06-22T10:55:25Z2010-06-22T10:55:25ZDependency across mediators<div><p>Hi Kyma</p>
<p>the eventDispatcher is injected into the base classes of the
Command, Mediator and Actor classes - so it's available to any
class extending those. It is actually called 'eventDispatcher'. (I
can see now how that could be confusing!).</p>
<p>It's a single instance of an IEventDispatcher - so if you
dispatch an event in a command, mediator or actor (model or
service) then every class in your app which extends the base
Mediator or Actor has the opportunity to listen for it. So - rather
than listening for events on specific objects, you listen on this
shared dispatcher.</p>
<p>The dispatch(evt) function which is available in classes that
extend Command, Mediator or Actor is a short form of:</p>
<p>eventDispatcher.dispatchEvent(evt)....</p>
<p>it's just there in Command / Mediator / Actor as a
convenience.</p>
<p>Generally, you would use the eventMap in the Mediator to listen
for events on your view, and on the shared dispatcher. Your code
would look like this:</p>
<p>onRegister():void<br>
{</p>
<pre>
<code>eventMap.mapListener(view, MouseEvent.CLICK, viewClickHandler);
eventMap.mapListener(eventDispatcher, SomeEvent.SOMETHING_HAPPENED, somethingHappenedHandler);
... and more code like this!</code>
</pre>
<p>}</p>
<p>The reason for using the eventMap and not just doing</p>
<p>eventDispatcher.addEventListener....</p>
<p>is because the eventMap has code for cleaning itself up when the
mediator is automatically destroyed if the view leaves the
stage.</p>
<p>Usually, Services and Models only dispatch events. They don't
listen for them. If you want to respond to an event by using a
service or updating a model, this is where you would map a Command
to the event in your context, and use the command to call on the
service or model API.</p>
<p>It sounds like you could maybe do with some extra background?
There are some very good 'getting started' articles on the site,
and Joel has written some for Adobe too.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/20295552010-06-22T11:03:48Z2010-06-22T11:03:49ZDependency across mediators<div><p>That all makes sense. Everything's working nicely now. Thanks
for your help</p></div>Kyma