tag:robotlegs.tenderapp.com,2009-10-18:/discussions/solutions/15-update-injections-in-a-mediator-from-a-commandRobotlegs: Discussion 2018-10-18T16:35:29Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/85994092011-07-14T07:52:57Z2011-07-14T07:52:57ZUpdate injections in a mediator from a command<div><p>Hi Simon,</p>
<p>you shouldn't re-inject an object at runtime. We don't support
that work flow at all.</p>
<p>This is one of the reasons that we don't advise injecting other
things into Mediators - just their view.</p>
<p>In the next version (1.6) of Robotlegs (out within the next week
or so) you can't inject Mediators into other objects at all - it
was something that was an accidental by product of how the mediator
mappings were carried out.</p>
<p>You should fire an event from your mediator which you pick up in
the Command and send to the service. And your service should fire
an event (or a model should, after update by the service) which the
mediator picks up to give the result to the view.</p>
<p>So - unfortunately the answer is "Don't inject services into
your Mediator". Timing issues like these are part of the reason why
we advise against it.</p>
<p>The alternative is that you use a Service locator ... which is a
very un-Robotlegs way to do things, but would work.</p>
<p>If you're absolutely sold on not changing things, then the
following code in your command would achieve what you want...</p>
<pre>
<code>[Inject]
public var theMediator:TheMediator;
override public function execute():void
{
injector.unmap(ISearchService);
injector.mapSingletonOf(ISearchService, TwitterSearchService);
var serviceInstance:ISearchService = injector.getInstance(ISearchService);
theMediator.searchService = serviceInstance;
}</code>
</pre>
<p>However - this will mean you can't update to the next version of
Robotlegs when it comes out.</p>
<p>But you should really just try out the events approach - it's
very, very reliable.</p>
<p>I'm sorry if that's not what you wanted to hear!</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/85994092011-07-14T16:57:49Z2011-07-14T16:57:50ZUpdate injections in a mediator from a command<div><p>Thanks for your reply!</p>
<p>That's just what I wanted to hear! :-) I did feel that it wasn't
very clean to inject the mediator, I just couldn't come up with
anything that seemed more logical.</p>
<p>However, I'm not quite sure I understand your solution. What I
intended was simply to swap the <code>TwitterSearchService</code>
and <code>OtherSearchService</code> in the mapping of
ISearchService, because I thought it better than doing some sort of
conditional (in the mediator that requests data) against a model;
something like:</p>
<pre>
<code>if (someModel.service == "twitter")
twitterSearch.getResults()
else if (someModel.service == "other")
otherSearch.getResults()</code>
</pre>
<p>I'm not sure I'm explaining myself right here, but I hope you
get the idea.</p>
<p>Is the unmapping and remapping of a new class not the way at
all? To me it seems incredibly simple and clean, and the "only"
thing missing is the updating of the mediator.</p></div>simontag:robotlegs.tenderapp.com,2009-10-18:Comment/85994092011-07-14T17:08:02Z2011-07-14T17:08:02ZUpdate injections in a mediator from a command<div><p>Hi Simon,</p>
<p>what you could do is send an event from your mediator rather
than try to use the service directly.</p>
<p>That way you can still map / unmap your service, but because the
command is created only when the event fires, it will always use
the correct version of the service.</p>
<p>so - I'd avoid putting the service direct into your mediator,
then your problem goes away.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/85994092011-07-14T17:44:27Z2011-07-14T17:44:28ZUpdate injections in a mediator from a command<div><p>Ah! That sounds good! Thanks a lot! :-)</p></div>simon