PermissionsLoader

Joseph Marques jmarques at redhat.com
Fri Dec 17 02:22:10 UTC 2010


On 12/16/2010 03:56 PM, John Mazzitelli wrote:
> I introduced a new PermissionsLoader object and refactored all uses of
> GWTServiceLookup.getAuthorizationService() so it uses the new loader.
>
> This DOES NOT CACHE any permissions. However, it now provides a single
> place where all loading of permissions will/should take place (assuming
> everyone uses it now).
>
> to use:
>
> new PermissionsLoader().loadExplicitGlobalPermissions(new
> PermissionsLoadedListener() {
>      public void onPermissionsLoaded(Set<Permissions>  perms) {
>         ...do your thing...
>      }
> });
>
> There are some benefits:
>
> 1) I looked at all uses of the AuthorizationService and they all had the
> same pattern - onFailure() always logged a error message (but some
> people duplicated Message.properties, even though they said basically
> the same thing). onFailure rarely did anything else - if it did
> something else, it was usually small, ~1 line of code. This
> PermissionsLoader now provides you the onFailure code so we don't have
> to cut-n-paste the same thing everywhere. And it therefore consistently
> provides the same error message ("Failed to load the permissions - you
> have none" or something like that). if you really need the exception
> that occurred, you can get it from getLastError of the loader object
> (but in all the usages of AuthorizationService, no one needed the
> exception except to log it, which the loader now does for you).
>
> 2) You now only have to implement a single callback method -
> onPermissionsLoaded. You will be given all permissions that you have as
> the argument to that method - see javadoc for more.
>
> 3) We now have a single place where all permissions loading will take
> place that will allow us to track the loading of permissions in the app
> on the client side and will allow us to more easily introduce either a)
> some caching in the future if we deem it necessary and/or b) code that
> can help limit the amount of times we ask for the same kind of
> permissions multiple times in the same request.
>
> 4) I cut down the number of lines of code needed and the code around
> auth perm loading is now less cluttered.
Items 1, 2 & 4 are largely the same thing.  Could be phrased as 
"duplicate failure handling code was centralized, but can be overridden."

As for 3, we have client-side GWT service monitoring at the 
infrastructure level so that any remote services you write automatically 
get tracked -- 
http://josephmarques.wordpress.com/2010/11/29/performance-monitoring-using-gwt/ 
-- in this case you'd want to look at stats for (any method in) 
AuthorizationGWTService.

For the record, I'll *almost always* be against these types of 
"enhancements", so I'm hoping this doesn't become a common 
"optimization" we look for.  We're trying to looking for ways to save 
minute amounts of typing or a few lines of code because we think there's 
a slight overlap between logic in two or more parts of the application.  
However, in doing so, we're introducing more classes that the developer 
has to be aware of (SomeDataLoader instead of everyone going through 
GWTServiceLookup).  Then if we do want specific error messages -- and I 
absolutely think we should be striving for the most specific error 
messages whenever possible -- you need to test for a null result set 
(which, in certain circumstances, might actually be a valid value for 
the underlying remote service) and then override the default handling, 
or lookup the lastError and display an appropriate message.  Does this 
really simplify anything?

We really need to embrace the asynchronous nature of GWT and get used to 
the fact that these callbacks have required boilerplate that go along 
with them...and that's fine.  It is what it is.  If we really want to 
improve how the application is structured architecturally, let's see if 
we can start incorporating some of these concepts -- 
http://www.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html 



More information about the rhq-devel mailing list