Re: extend UiBinder engine

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 google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.