Two Mediators and a command to change one...

maggelo's Avatar


11 Oct, 2011 11:35 PM

Hi all,

I'm having a problem i can't find a decent solution to:

I'm trying to modify a textfield in a view (page title) through a command that's being executed from within another mediator. both mediators are coming onscreen at the same time.

I have 2 views (with 2 mediators) coming on screen at the same navigation state.
At the end of the transitionIn() method of one mediator, i dispatch a signal and thus a command (mapped signalCommand).
This command's function is to modify something in one of the two mediators, that are on screen now. This gives me a runtime error,
saying that one of the injected variables in the command (the mediator that is to be modified) cannot be injected:

Error: Injector is missing a rule to handle injection into target [object ChangePageTitleCommand]. Target dependency: nl.powergeek.hightide.views.mediators::AppContextMediator

Does anyone know a solution for this right away, or do i have to create an example to show the problem i'm having?
Do i simply not inject mediators into commands? What other way should i use?

  1. Support Staff 1 Posted by Stray on 11 Oct, 2011 11:49 PM

    Stray's Avatar

    Hi there,

    you can't inject mediators into other objects - and a mediator should be light with no api beyond onRegister / onRemove, so the normal practice is to only communicate with mediators via events.

    Your command can dispatch an event for the mediator to catch, or, if you're only dealing with transitions here, you can inject the same signal into both mediators and wire it up that way.



  2. 2 Posted by maggelo on 12 Oct, 2011 12:05 AM

    maggelo's Avatar

    Hi Stray,

    Thanks for the fast reply AND clearing the first two things up!
    I presume this has been said by you to beginning RobotLeg developers a million times.

    I think i should redesign the whole flow then... I'm adding data to the Signal, which comes from the view itself (it's name, or 'page title').

    What should be the place to store information about a specific view? A model specific to that view, or the view itself (this is where i store the name of the view currently)?

  3. 3 Posted by Pierre Laveklin... on 12 Oct, 2011 06:26 AM

    Pierre Laveklint's Avatar

    I'm not exactly sure what you're going for here...

    You could store a views properties/setup in a VO(value object), that get passed to the view either by the views API or is the constructor (DI).

    I'm don't see how your first question applies to where you store a views properties?

    Can you please try to explain a bit more?

  4. Support Staff 4 Posted by creynders on 12 Oct, 2011 06:28 AM

    creynders's Avatar

    It's one of the hard things when starting out with RL or MVC in particular: defining the boundaries between the different tiers and what goes where. I know I struggled a lot with it and actually still do.

    Now, none of what follows is set in stone, nor is it without exceptions, so keep that in mind.

    In general models are used for 2 things: storing application data/state and manipulating that data.
    It doesn't mean all data needs to be put in a model. Only data that is shared amongst actors in the application or data that needs to persist beyond the life cycle(s) of a(n) actor(s).
    Does this mean view data is never stored in models? No, but only if it needs to be shared or needs to persist. (There are other reasons, but let's keep it simple)
    So the first thing you have to ask yourself is whether the data is shared by various actors.

    In your case you'd say it is, since you got two mediators accessing the same data, right?
    But another thing many people struggle with in the beginning is the tendency to let all communication between elements go through the framework/system, while in reality that's not necessary, especially when it comes to views.
    In my mind application logic actually falls into one of two categories: view logic or business/system logic. Roughly speaking all view logic needs to go in the view tier and all business logic goes into the other 3 tiers: model, service, controller. This is definitely debatable and the boundaries are sometimes very blurred, but it really helped me to start analyzing my applications with that dichotomy in mind.

    Now let's take a look at your case:
    You have 2 views coming on screen at the same navigation state. Now this sounds to me that these 2 views are actually coupled to each other, that one won't exist w/o the other. In my experience, every time that happened, those two views were actually one view.
    A view can consist out of one display object, but it can also exist out of hundreds. It would actually be better to think of views as view components, but since component has so many meanings, especially in flash, I try to avoid using that term. But that's what a view basically is: a collection of display objects, all working together presenting the same view data. These display objects can have dependencies on each other and communicate with each other, all w/o the rest of the system having any knowledge about what's going on there.

    So, that's the next question you need to be asking yourself: are these really 2 separate views or actually one view with different parts?
    When will it be the former? If you need to reuse one of both in a different context (not talking about RL context), but still accessing exactly the same data. Or if they need to exist separately from each other. But if you realize that you'll always be using both views together, then actually they are one view.
    In that case the solution is to create a containing display object and mediate that instead of the 2 parts separately.


    Another thing: mediators really should be that: mediators. They are middle men between the views and the rest of the system. They should have no logic at all. They receive or pull data and pass it to or pull it from their views. They relay signals from view to system and back. And that's it.
    Mediators shouldn't know whether their views are transitioned in or not, they are not view controllers.

  5. 5 Posted by maggelo on 12 Oct, 2011 06:48 PM

    maggelo's Avatar

    Thanks for all the fast replies, love that! Sorry for the confusion.
    The situation is that i have some screens (separate views and mediators with separate functionality), and on top of some of those views lies another view (2 'bars'. 1 topbar, 1 bottombar, in one view with a mediator). so at times, there are 2 views and 2 mediators active (a random screen, with overlayed the bottom- and top bars.)

    The topbar is quite generic, it has a back button, textfield and a settings button.
    the bottom bar has 4 'tab bar' navigation items.

    What i want to achieve is that the textfield in the topbar will display the 'name' of the view that is currently active beneath it!

    So, that's to make my second reply clear :) i currently store the name of the underlying view in the view itself. is this a good place to store the name of the view?
    and then, what is the best way to get it to display in another view? since they are both coming on screen at the same time? (the top- and bottom bars are not visible on all screens so they transition in at the same time a view transitions in)

    I hope my question is a lot more clear now :)

  6. Ondina D.F. closed this discussion on 23 Dec, 2011 08:55 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac