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