Changing Mediator on the fly
Hi,
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.
Thanks,
Varun
Comments are currently closed for this discussion. You can start a new one.
Keyboard shortcuts
Generic
| ? | 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
1 Posted by Stray on 06 Jul, 2012 12:19 PM
Are you using Robotlegs 1 or 2?
2 Posted by varunchopra18 on 06 Jul, 2012 12:38 PM
1.4 i guess
3 Posted by Stray on 06 Jul, 2012 12:41 PM
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).
Stray
4 Posted by varunchopra18 on 06 Jul, 2012 12:44 PM
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?
-Varun
Support Staff 5 Posted by Till Schneidere... on 06 Jul, 2012 01:03 PM
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 Posted by varunchopra18 on 06 Jul, 2012 01:15 PM
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?
-Varun
7 Posted by Stray on 06 Jul, 2012 01:20 PM
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.
Stray
8 Posted by varunchopra18 on 06 Jul, 2012 01:27 PM
In my use case I want to give different behavior to my component by changing mediators in runtime.
-Varun
9 Posted by Stray on 06 Jul, 2012 01:38 PM
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.
hth,
Stray
10 Posted by varunchopra18 on 08 Jul, 2012 09:12 AM
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.
-Varun
11 Posted by Stray on 08 Jul, 2012 09:59 AM
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.
Stray
12 Posted by varunchopra18 on 08 Jul, 2012 11:18 AM
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 Posted by Stray on 08 Jul, 2012 07:13 PM
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 Posted by varunchopra18 on 09 Jul, 2012 08:07 PM
Thanks Everyone.
varunchopra18 closed this discussion on 09 Jul, 2012 08:08 PM.