Different Views for Different Users
Hi,
I understand Robotlegs is more focus on just presentation layer but it may still couple with business layer more or less. E.g. a system enable certain features for different kind of users (adminstrator, moderator, normal user, guest etc). Should we tight the view mediator with user model so it can decide what (buttons, links) should be visible or have multiple set of views for different type of users then inject to context? The former requires less code but couples view mediator with model, the latter seems like may harder to maintain and bring down productivity. Which way I should choose? It would be great if someone can point a link to existing example.
Thanks.
Comments are currently closed for this discussion. You can start a new one.
2 Posted by creynders on 30 May, 2011 08:07 AM
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.
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.
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.
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.
3 Posted by Amy Blankenship on 30 May, 2011 04:54 PM
You could also use PresentationModel http://blogs.adobe.com/paulw/archives/2007/10/presentation_pa_3.html. 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.
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.
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).
4 Posted by cklee75 on 31 May, 2011 09:05 AM
Thanks for both of your replies.
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.
@creynders. Yes, my backend will ensure authorization with Spring Security.
Thanks.
5 Posted by Weyert on 31 May, 2011 11:34 AM
Maybe you can use a view factory which creates the appropriate view based on the user.
Support Staff 6 Posted by Joel Hooks on 31 May, 2011 06:35 PM
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.
It adds another layer of security and flexibility.
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.
7 Posted by Stray on 31 May, 2011 09:40 PM
That describes exactly how we do it. Different users get a different 'mix' of modules - delivered by the server. Remember that modules don't *have* to be visual - so you can also deliver non visual functionality differences this way.
8 Posted by Stray on 31 May, 2011 10:14 PM
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?
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.
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...
Sx
cklee75 closed this discussion on 20 Aug, 2011 12:32 AM.