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