tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/569-different-views-for-different-usersRobotlegs: Discussion 2018-10-18T16:35:28Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/75356042011-05-30T08:07:31Z2011-05-30T08:07:31ZDifferent Views for Different Users<div><p>It all depends on the use case(s), I think. For some views I can
definitely see the advantages of having them injected depending on
user rights. It depends on the amount of differences between
potential actions a user can take, I think.</p>
<p>But in no way should the mediator be coupled to the model. You
can do that of course, but I'd advise against it. There's a bunch
of solutions to avoid that. For instance: even if there are 5
different roles, some views will probably only define 3 different
states. Let the mediator decide which of those 3 states should be
shown depending on the real user role in the model.</p>
<p>I think I'd choose the multiple sets of views approach though
and have a separate document that defines which views will be shown
depending on user role.</p>
<p>Remember, flash is in no way secure, always - ALWAYS - let the
backend determine if a user is allowed to perform an action, never
solely trust on the frontend.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/75356042011-05-30T16:54:37Z2011-05-30T16:54:38ZDifferent Views for Different Users<div><p>You could also use PresentationModel <a href=
"http://blogs.adobe.com/paulw/archives/2007/10/presentation_pa_3.html">
http://blogs.adobe.com/paulw/archives/2007/10/presentation_pa_3.html</a>.
When you use PM, you can inject a reference to the context's
eventDispatcher, so there's no actual need for a Mediator if you
use viewMap to allow your view to receive injections.</p>
<p>You could do something like having a variable on the PM for the
user's role, and the View can bind to that to determine its
currentState.</p>
<p>Another option is to have all your views implement an interface
and allow the Injector to build the correct View for you based on
the current mapping (which you'd set up from a Command once the
role is set).</p></div>Amy Blankenshiptag:robotlegs.tenderapp.com,2009-10-18:Comment/75356042011-05-31T09:05:25Z2011-05-31T09:05:25ZDifferent Views for Different Users<div><p>Thanks for both of your replies.</p>
<p>This is a common business use cases (different views for
different users). Just wonder anyone can share examples for all
different approaches and let others to evaluate the best for their
case.</p>
<p>@creynders. Yes, my backend will ensure authorization with
Spring Security.</p>
<p>Thanks.</p></div>cklee75tag:robotlegs.tenderapp.com,2009-10-18:Comment/75356042011-05-31T11:34:48Z2011-05-31T11:34:48ZDifferent Views for Different Users<div><p>Maybe you can use a view factory which creates the appropriate
view based on the user.</p></div>Weyerttag:robotlegs.tenderapp.com,2009-10-18:Comment/75356042011-05-31T18:35:26Z2011-05-31T18:35:26ZDifferent Views for Different Users<div><p>So to expand on some good advice about multiple views, if you
want to add another layer of security to that you could seliver the
appropriate view as a swf module from the server to the user based
on their credentials as defined by their current session. The
module would conform to an interface, so the application wouldn't
care which actual view it was and the module would contain only the
functionality available to it.</p>
<p>It adds another layer of security and flexibility.</p>
<p>I'm less hesitant to simply inject the model into your mediator
as needed. A UserPermissionModel seems like a reasonable
dependency. Appropriate coupling being the goal. As opposed to
strictly loose coupling.</p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/75356042011-05-31T21:40:42Z2011-05-31T21:40:42ZDifferent Views for Different Users<div><p>That describes exactly how we do it. Different users get a
different 'mix' of modules - delivered by the server. Remember that
modules don't <em>have</em> to be visual - so you can also deliver
non visual functionality differences this way.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/75356042011-05-31T22:14:35Z2011-05-31T22:14:35ZDifferent Views for Different Users<div><p>Oh - and I meant to say - I agree that this is a low-risk
injection - really it sounds like you're not injecting a 'model' -
it's more like a config VO? Created once and then constant in its
state?</p>
<p>If it does have mutable state (setters, transformation functions
etc) I'd inject it against an interface that only exposes the
getters that are fair game in the mediator - this not only makes
your intention clearer, it also decreases the possibility of
abusing the injection in the future, when you may have forgotten
your good intentions - or when it's someone else doing an
update.</p>
<p>The hot-water to watch out for is doing much more than simply
passing values from this model to the mediator. If you need to do
some 'translation' (eg assembling the data together or putting it
into a strong typed VO that the view API expects) that's cool. If
you start using it for logic - switches, if-statements etc, I'd be
a little more wary. As Joel says, appropriate coupling is the goal,
but Joel and I have both observed that logic-in-mediators is the
first step on the route to insanity...</p>
<p>Sx</p></div>Stray