Home → Robotlegs 2 →

Child Injection for Mediators

• Edit

Seven

21 Apr, 2016 08:02 AM

Hey.
I would like to know if it's possible to use a child injector with mediators? Like say I have a view group what I want it to have a "UpdateSignal" But I don't want all mediators to run on the same signal. Each sub group would get it's own.

Is this possible?

1. Support Staff 1 Posted by Ondina D.F. on 22 Apr, 2016 11:49 AM

   

   Hi Seven,

   You can create a childInjector like this:

   var someChildInjector:IInjector = injector.createChild();
   injector.map(IInjector, "someChildInjector").toValue(someChildInjector);
   

   and then inject it into a class as a named injection to distinguish it from other injectors:

   [Inject (name="someChildInjector")]
   public var someChildInjector:IInjector;
   

   Now the problem is, that if you map your UpdateSignal like this:
   someChildInjector.map(UpdateSignal).asSingleton();

   and you inject UpdateSignal into a mediator that has been mapped to its view by the parent Injector, the parent Injector will complain about a missing mapping for UpdateSignal, because it doesn't know anything about the mappings performed by the childInjector. So, what are you going to do? Something like this?:

   var updateSignal:UpdateSignal = someChildInjector.getInstance(IInjector, "someChildInjector");         
   updateSignal.add(onUpdatedRequested);
   

   And if you have 10 mediators, would you create 10 childInjectors and 10 named injection points?
   I don't think that the above is a good solution. It makes things difficult to manage.

   More info about child injection ( old SwiftSuspenders version but the principles are the same in the new version):
   https://github.com/tschneidereit/SwiftSuspenders/tree/childinjector...

   https://github.com/robotlegs/swiftsuspenders/blob/master/test/org/s...

   Do you need a modular approach? Each View with its own context? If so, you don't need to create the child injectors manually. I can tell you more about Modules in case that's what you need.

   Possible solutions for a single Context application :

   • create separate signals, with different names of course, for each mediator ( which is better than having separate injectors for each mediator!!)

   • one signal, UpdateSignal, with an additional parameter used by a mediator to check if the message is meant for it ( a view id or some other conditional )

   • use the request/response pattern introduced by Stray:

   http://knowledge.robotlegs.org/discussions/problems/322-request-mod...

   http://knowledge.robotlegs.org/discussions/problems/213-no-subject

   https://gist.github.com/Stray/664521

   http://knowledge.robotlegs.org/discussions/questions/585-loading-da...

   http://knowledge.robotlegs.org/discussions/questions/937-separating...

   http://knowledge.robotlegs.org/discussions/problems/681-response-fr...

   If none of the above solves your problem, you need to tell me more about your use case. For example, I'd like to know which class is dispatching the UpdateSignal. Is it a Service class after receiving data from a remote source?
   Maybe the solution is much more simple...

   Ondina

   [EDIT]

   If your UpdateSignal was meant to be dispatched by the views so that their mediators can forward the request to a command in order to update a model's data or to send view's data to a remote server via a service call, you can use a 'bland' signal in the views like this:

   Inside the Views:

   public var viewToMediatorSignal:Signal;

   somewhere where you are initializing your views:

   viewToMediatorSignal = new Signal( SomeVO );

   somewhere where you need to dispatch it:

   viewToMediatorSignal.dispatch( someData );//where someData is of type SomeVO

   Inside your Mediators' initialize()
   view.viewToMediatorSignal.add( onSomeRequestFromView );

   Inside of onSomeRequestFromView:

   you can dispatch a signal that was mapped as singleton and injected into your mediator(s), say your UpdateSignal, which will carry the payload from the viewToMediatorSignal and will trigger a command ...and so on...

   Don't forget to remove the listeners for the viewToMediatorSignal in the destroy() method of your mediator, if the view needs to be removed from stage.

   • Edit

2. Support Staff 2 Posted by Ondina D.F. on 22 Apr, 2016 02:14 PM

   

   see the edited answer above

   • Edit

3. 3 Posted by Seven on 25 Apr, 2016 07:37 AM

   

   Hey Ondina,
   Thanks for your response. It clarified that I probably can't improve the current architecture of my project. We already use signals from views like this, but it often leads to Hot Potato signal pattern which is ugly and difficult to follow.

   What I was hoping to solve was that say, the character window, has one main view and many sub components with their own views/mediators. and you click on an item and "try on" the item. Almost all components of the larger window need to react to the input. Currently we have many signals "CharcterWindowUpdateSignal", "SkillsWindowUpdateSignal" which has lead to some issues where nested components have their own internal signals which work indipentantly "ResearchUpdateSignal" is confused with "ResearchesUpdatSignal". This causes confusion because the injection points are filled by the mediator mapper but you get no responses from the signals.

   So I was hoping to solve this by using a child injector to reduce useless class duplication just to rename the class. But it looks from your answer that this isn't possible with the mediators.

   It did help confirm that another use case I wondered about is possible.

   Thanks!

   • Edit

4. Support Staff 4 Posted by Ondina D.F. on 27 Apr, 2016 10:58 AM

   

   Hey Seven,

   You're welcome!

   Thanks for providing more info, but, as you can guess, it's still not enough for me to understand the structure and workflow of your application. There are many possible scenarios, and speculating about one or another would be counterproductive. Using signals from views like in my example shouldn't per se lead to a Hot Potato antipattern. There might be other contributing factors causing such a behavior.

   "ResearchUpdateSignal" is confused with "ResearchesUpdatSignal". This causes confusion because the injection points are filled by the mediator mapper but you get no responses from the signals.

   Who is confusing ResearchUpdateSignal with ResearchesUpdatSignal? The programmer? The Injector wouldn't confuse them, if they were properly mapped (rule) and injected (injection point). Are you using a "regular" Robotlegs Mediator or something like a SignalMediator or a StarlingMediator?

   But, maybe that's not relevant anymore, since you are having another solution in mind already.
   Just let me know whether there is still something I can help you with or I can mark the issue as resolved and close the thread.

   Ondina

   • Edit

5. Ondina D.F. closed this discussion on 12 May, 2016 12:07 PM.