Changing Mediator on the fly

varunchopra18's Avatar


06 Jul, 2012 12:13 PM


Is it possible to change the mediators mapping after component instantiation? For instance, I have added a button in view which is not mapped initially but I want to map a mediator to that button. Is it possible? If yes then how?

Note: I have created my own custom component to which i want to map mediator so that where ever i have used the component in my application it will apply the new mediator.


  1. 1 Posted by Stray on 06 Jul, 2012 12:19 PM

    Stray's Avatar

    Are you using Robotlegs 1 or 2?

  2. 2 Posted by varunchopra18 on 06 Jul, 2012 12:38 PM

    varunchopra18's Avatar

    1.4 i guess

  3. 3 Posted by Stray on 06 Jul, 2012 12:41 PM

    Stray's Avatar

    Cool, in that case there's a createMediator(viewInstance) function on the mediator map.

    You'd still map the rule as normal, and when you want to fire up the mediator, use createMediator().

    The only question I have is: why?

    Other than performance, I don't know of great use-cases for manual mediation, so I'm intrigued (either you have a great use case, which we'd like to know about, or there is a better way to solve your problem).


  4. 4 Posted by varunchopra18 on 06 Jul, 2012 12:44 PM

    varunchopra18's Avatar

    I don't think this solution will work for me because i have n-Number of instances of my component for which i want to add mediator. As per your solution i need all the instances to create mediator which is not feasible for me.

    Is there any other solution?


  5. Support Staff 5 Posted by Till Schneidere... on 06 Jul, 2012 01:03 PM

    Till Schneidereit's Avatar

    Think about it this way: If having access to all instances is not
    feasible even with specific knowledge of your exact use-case, then
    it's even more unlikely to be feasible for a general-purpose framework
    like Robotlegs.

    Having said that, I'd suggest using some sort of a registry in which
    to register all instances through the mediator they're first mediated
    by. That registry could have a method `addMediatorToExistingInstances`
    or similar.

  6. 6 Posted by varunchopra18 on 06 Jul, 2012 01:15 PM

    varunchopra18's Avatar

    I agree, there are workarounds but i am looking for robotlegs internal functionality to achieve this.

    One more question in addition to this, suppose i achieve this by the method you have given. But can i change the mediator for the same component again? How that will be achieved? I think we need to remove mediator from all the instances then map new mediator to view and create mediator instances again. Am I right?


  7. 7 Posted by Stray on 06 Jul, 2012 01:20 PM

    Stray's Avatar

    Hi Varun,

    we don't support this internally because it's - usually - bad design.

    What's your use case?

    You shouldn't need to swap a mediator mid app. Even Robotlegs 2 doesn't support this (unless the view is reparented into a new role).

    I think there is probably a much better way to achieve what you need.


  8. 8 Posted by varunchopra18 on 06 Jul, 2012 01:27 PM

    varunchopra18's Avatar

    In my use case I want to give different behavior to my component by changing mediators in runtime.


  9. 9 Posted by Stray on 06 Jul, 2012 01:38 PM

    Stray's Avatar

    Hi Varun,

    that doesn't really give me your use case: what's the usage - as in, what's happening in terms of user stories that requires this behaviour?

    For example "The user has now logged in... "...

    One solution that can work (without becoming hard to understand) is to use differently typed containers for the view. Each of those containers is mapped to a different mediator, and they represent the different 'states' you require in terms of mediation. Then at run time you add the correct container, add the component to this container, and remove the container that is no longer required.

    This is analogous to the same component being inside an edit panel vs a preview panel.

    It is subtly but importantly different from other strategies for changing the mediator at runtime - the 'purpose' belongs to the container, and the implementation (the fact that you are adding the same view component to it internally) is incidental.

    In most cases, the container view would only expose the relevant API for its purpose.



  10. 10 Posted by varunchopra18 on 08 Jul, 2012 09:12 AM

    varunchopra18's Avatar

    Hi Stray,

    I totally understand your point. I don't have a direct use case, its more like i am experimenting few things.

    For example think about a use case: Where we have a form which have different behavior depending on the user role. There can be multiple ways to implement this use case, one way is : we create many mediators, each defining one user role, and attach to view on the basis of user role. In this case the run time memory consumption will be less in compared to a mediator have code for all user roles.

    I am just trying to use robotlegs to minimize runtime memory consumption.


  11. 11 Posted by Stray on 08 Jul, 2012 09:59 AM

    Stray's Avatar

    Does the user role vary at run time (within a single run of the software)?

    One solution in these cases is to vary the mapping based on the user role.

    Otherwise I'd suggest using a container as I described before.


  12. 12 Posted by varunchopra18 on 08 Jul, 2012 11:18 AM

    varunchopra18's Avatar

    User can logout and relogin with another account having different role.

    Mapping can only be done once but if user is logging in again with different role then we need to change mapping.

  13. 13 Posted by Stray on 08 Jul, 2012 07:13 PM

    Stray's Avatar

    You *can* map and unmap. However, the container-per-role solution is, IMO, much more understandable. I see no reason not to take that approach.

  14. 14 Posted by varunchopra18 on 09 Jul, 2012 08:07 PM

    varunchopra18's Avatar

    Thanks Everyone.

  15. varunchopra18 closed this discussion on 09 Jul, 2012 08:08 PM.

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