tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/616-changing-mediator-on-the-flyRobotlegs: Discussion 2012-07-13T07:06:47Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-06T12:19:56Z2012-07-06T12:19:56ZChanging Mediator on the fly<div><p>Are you using Robotlegs 1 or 2?</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-06T12:38:09Z2012-07-06T12:47:38ZChanging Mediator on the fly<div><p>1.4 i guess</p></div>varunchopra18tag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-06T12:41:10Z2012-07-06T12:41:10ZChanging Mediator on the fly<div><p>Cool, in that case there's a createMediator(viewInstance)
function on the mediator map.</p>
<p>You'd still map the rule as normal, and when you want to fire up
the mediator, use createMediator().</p>
<p>The only question I have is: why?</p>
<p>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).</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-06T12:44:27Z2012-07-06T12:47:38ZChanging Mediator on the fly<div><p>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.</p>
<p>Is there any other solution?</p>
<p>-Varun</p></div>varunchopra18tag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-06T13:03:17Z2012-07-06T13:03:17ZChanging Mediator on the fly<div><p>Think about it this way: If having access to all instances is
not<br>
feasible even with specific knowledge of your exact use-case,
then<br>
it's even more unlikely to be feasible for a general-purpose
framework<br>
like Robotlegs.</p>
<p>Having said that, I'd suggest using some sort of a registry in
which<br>
to register all instances through the mediator they're first
mediated<br>
by. That registry could have a method
<code>addMediatorToExistingInstances</code><br>
or similar.</p></div>Till Schneidereittag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-06T13:15:26Z2012-07-06T13:15:26ZChanging Mediator on the fly<div><p>I agree, there are workarounds but i am looking for robotlegs
internal functionality to achieve this.</p>
<p>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?</p>
<p>-Varun</p></div>varunchopra18tag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-06T13:20:38Z2012-07-06T13:20:38ZChanging Mediator on the fly<div><p>Hi Varun,</p>
<p>we don't support this internally because it's - usually - bad
design.</p>
<p>What's your use case?</p>
<p>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).</p>
<p>I think there is probably a much better way to achieve what you
need.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-06T13:27:01Z2012-07-06T13:27:01ZChanging Mediator on the fly<div><p>In my use case I want to give different behavior to my component
by changing mediators in runtime.</p>
<p>-Varun</p></div>varunchopra18tag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-06T13:38:29Z2012-07-06T13:38:29ZChanging Mediator on the fly<div><p>Hi Varun,</p>
<p>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?</p>
<p>For example "The user has now logged in... "...</p>
<p>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.</p>
<p>This is analogous to the same component being inside an edit
panel vs a preview panel.</p>
<p>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.</p>
<p>In most cases, the container view would only expose the relevant
API for its purpose.</p>
<p>hth,</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-08T09:12:05Z2012-07-08T09:12:05ZChanging Mediator on the fly<div><p>Hi Stray,</p>
<p>I totally understand your point. I don't have a direct use case,
its more like i am experimenting few things.</p>
<p>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.</p>
<p>I am just trying to use robotlegs to minimize runtime memory
consumption.</p>
<p>-Varun</p></div>varunchopra18tag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-08T09:59:06Z2012-07-08T09:59:06ZChanging Mediator on the fly<div><p>Does the user role vary at run time (within a single run of the
software)?</p>
<p>One solution in these cases is to vary the mapping based on the
user role.</p>
<p>Otherwise I'd suggest using a container as I described
before.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-08T11:18:52Z2012-07-08T11:18:52ZChanging Mediator on the fly<div><p>User can logout and relogin with another account having
different role.</p>
<p>Mapping can only be done once but if user is logging in again
with different role then we need to change mapping.</p></div>varunchopra18tag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-08T19:13:41Z2012-07-08T19:13:41ZChanging Mediator on the fly<div><p>You <em>can</em> map and unmap. However, the container-per-role
solution is, IMO, much more understandable. I see no reason not to
take that approach.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/171354892012-07-09T20:07:51Z2012-07-09T20:07:51ZChanging Mediator on the fly<div><p>Thanks Everyone.</p></div>varunchopra18