Re: extend UiBinder engine

Hi Jens and Joseph,

Thanks for your interest in the post.

Jens, I didn't comment your solution because it doesn't fulfill my needs: 

@RequiresRole("superAdmin")

@UiField

CheckBox makeAdmin 

this code is too specific for me: I'm creating a CMS and I cannot attach hardcoded roles to my fields: each solution will make its own decision on what fields are allowed for which profile. In addition, I believe all security aspects should be kept outside of the main code: AOP is ideal because you don't want to add logic to the app, you only want to intercept a widget and say if it can be Viewed and/or Edited and maybe add some design hack, but you won't change the action that is tied to it or the information it displays. That's why I don't consider your proposition adequate for my needs

Joseph "GWT is not JSP" really? :-p (joking :-) )

I understand your point of view but 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.

"However GWT code is compiled down before runtime, so there is no foreknowledge of whether a user will meet the needed security roles at that time" : yes that's why the check has to be done in the generated code (where is exactly the issue?: it's always at render time that the security is evaluated, so in GWT I have to generate code that checks the security rules when executed: that's why I'm changing the Generator)

"The proper way to do this is to have an initializer in your presenter that will take a user object and properly show/hide or enable/disable the components of interest at runtime display of your widget. "

I don't agree with this statement neither since as I told before: mixing authorization inside the code is creating spaghetti code, it is better to either 

• extend standard Widgets to include security checks and ask a central engine if they can display (which I don't like since the widgets must be created to check if they done well to exist at all)
  
• 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

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 thinking about compiling GWT locally for the project needs to have a cleaner solution's source code, publish my patch to GWT and wait until the next release to get back to the official version...

Anyway, thanks a lot for your interventions, this discussion is good to motivate the adoption of the patch (as I mentioned, there's an open bug for the purpose)

--
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.