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 15:27:32 UTC 2011



On 8/17/2011 10:36 AM, Ian Springer wrote:
> On 08/17/2011 09:52 AM, Jay Shaughnessy wrote:
>> 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.
> Agreed.
>
>> 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?
> The only non-user-initiated call that is outside the context of a
> particular view that we could think of is the background call that
> periodically updates the alert count at the top of the page. Although
> calls to periodically auto-refresh portlets or other data in the current
> view are technically non-user-initiated, they are still in the context
> of a particular view and so could still be assigned a tracking uuid.
I'm not 100% sure but we may have some stuff going on in the session 
manager code.
>
>> 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.
> That's a good point. One example I can think of is calls that update
> something on the Server side (e.g. uninventorying a Resource or creating
> an alert definition); ideally we'd still want to display a message
> informing the user the operation had completed, even if the user had
> navigated to a different page while the call was in progress. If we
> short-circuit the call to onSuccess() or onFailure(), we won't be able
> to display such a message...
>
>> Jay
>>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/rhq-devel
>


More information about the rhq-devel mailing list