Zied,
My apologies that my post was less than cogent. From you example, I thought
you wanted some compile time enforcement of roles. Given your example
UiBinder XML attribute: *visible={roles.admin} *, that would imply
foreknowledge of the roles at compile time given that *with* pulls in
constant values/accessors into the Ui template. However, given your
clarified need for a dynamic set of roles from your CMS, the roles wouldn't
be known at compile time for inlining into that UI template.
you should not forget GWT is a View technology, it is an HTML templating
> engine. From this point of view, Jsp and GWT do the same: they create
> HTML/js/css for the user's pleasure
GWT does indeed include a view framework, but very unlike JSP, there are
many things GWT does not know at runtime that JSP does know. Given this, it
is difficult to compile this knowledge ahead of time into the view, which
is why I would suggest such logic be in the presenter.
To this end, I'm a fan of *dumb views*. All the GWT widgets have visibility
methods and enable/disable methods where appropriate. Authorization is not
one of their concerns. The view itself should not necessarily contain the
logic for authorization and (IMHO) not the widget since is (typically) just
a simple HTML element wrapper with the simple responsibility of putting
tags in the DOM. For my applications this logic resides at the Presenter
layer (using GWT Platform) and the presenter can take the proper action to
secure the UI as needed, keeping the views simple.
the preferred solution is to work at the factory level: decide before
> creating a widget if it will be useful or not: that's why I chose this
> approach
For many GWT implementations such as single page applications with
simulated browser history like GWTP (which may not apply to your case), the
same widget is retained in the DOM and reused many times for the sake of
speed and conserving memory. In that case, the fact that the widget was
enabled/disabled at instantiation would prevent it's effective reuse for
another user/use case. However, if your presenter had a *secureView(
UserObj user)* or similar, your security delegate could properly secure the
UI as needed on demand and not have to rerender the entire view.
mixing authorization inside the code is creating spaghetti code
You could have a central class, say* ViewAuthorizationProcessor* which
presenters would delegate to and which could take the proper steps to
secure a view, say *ViewAuthorizationProcessor* *#secureView( SecureView
view, UserObj user)*. This would not be spaghetti code and would result in
a minimum amount of classes and wouldn't need to change the core GWT
generators or widgets. Using a simple authorization annotation, as Jen's
mentioned, you would just mark those widgets in your your UiBinder Java
file and everything else should work. Since your dynamic user roles would
presumably be groups of existing authorizations (i.e. *canEditCMSPost*),
this should work well as those could just be enum constants that are known
at compile time.
Anyway, my code will work, I raised a bug only to complain that I had to
> copy 20 classes instead of extending 1 class and overriding 1 method for
> the job to get done.
I'm certain your code will work and will realize the desired business
value. You're obviously a competent developer given your progress so far.
There are many ways for you to skin this cat and I'm sure you'll find one.
Thanks again for you question and comments. I'm sure everyone's proposed
solutions will be beneficial to others pursuing similar goals. I hope the
above helps.
Sincerely,
Joseph
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
