RHQ GUI: how to deal with user clicking to navigate to view X and then clicking to navigate to view Y before X has finished loading

Jay Shaughnessy jshaughn at redhat.com
Wed Aug 17 13:52:19 UTC 2011


A couple of thoughts on this.

Dropping async returns for obsolete user interactions should be a good 
way to eliminate unnecessary work, and may help avoid invalid work in 
various scenarios.  But it won't eliminate invalid work in that it can 
narrow the window of vulnerability but not close it entirely.  Once the 
async call returns it will still perform the processing in the 
callback.  That processing may still be subject to problems if the user 
navigates away while it is in progress.

What will be the mechanism to allow pass-thru for non-user-initiated 
async calls?  Calls where user navigation is irrelevant, like a 
background, timer-based call to collect information or perform some sort 
of task?  WIll there be a way to somehow tag the call as being 
untouchable?  Or perhaps another callback method outside of onSuccess 
and onFailure, like onContextChange?

Related, although I'm not sure this is really a valid use case, it may 
be required thata use-initiated call must have its callback invoked even 
if there is a context change.  For example, the async callback may need 
to itself invoke some sort of callback or listener on its completion.

Jay


More information about the rhq-devel mailing list