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 20:37:12 UTC 2011



On 8/17/2011 4:27 PM, Robert Buck wrote:
> Hi,
>
> Ian and I just chatted on the phone about the questions below. This
> email captures our thoughts/discussion points. See comments below.
>
> -Bob
>
> On 08/17/2011 01:16 PM, Ian Springer wrote:
>>>>> 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.
>> I see UserSessionManager.refreshHttpSession() which periodically hits
>> portal-war to keep its session alive, but it doesn't go through one of
>> our GWT RPC proxies to send the request, so we probably don't have to
>> worry about it.
>>
>> In any case, if we do find some other RPC calls that are outside the
>> context of a particular view/navigation, then I guess we can add a way
>> for the user to specify that the uuid stuff should be skipped when
>> requesting a proxy instance from GWTServiceLookup., e.g.:
>>
>> boolean skipViewUuid = true;
>> FooGWTServiceAsync fooService =
>> GWTServiceLookup.getFooService(skipViewUuid);
OK, I like this.  So when you ask for the service you can ask to have 
the calls invoked by that service instance skip the mechanism.  Instead 
of only a boolean perhaps an enumeration that had a couple of different 
values.  SKIP_TRUE, SKIP_FALSE (the default), SKIP_FAIL.  The last 
option could invoke the onFailure() method with a special Exception 
lthat would signal that the response was tossed but still give you the 
callback for app-level processing (almost like a finally).
>>
>>
>>>>> 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...
>> Does anyone have any thoughts on how we should deal with this?
> In this case the user elected to change to a different page, so we could
> for now just drop the notification entirely. In other cases when the
> user changed pages we drop the notification, but not from the message
> center (the AsyncCallback implementations handle the message center
> notification). So we could simply change the code to drop the
> notification in this one case, which should be rare, and I think it may
> be reasonable to allow it to be dropped if it makes the UI more stable.
>
> Ian pointed out an interesting case in ResourceSearchView:
>
>                           CoreGUI.getMessageCenter().notify(
>                               new
> Message(MSG.view_inventory_resources_uninventorySuccessful(),
> Severity.Info));
>                           ResourceSearchView.this.refresh();
>
> Here you see the .notify call but then a refresh. If the user moved away
> from the page and yet we permitted the callback to be called, the
> .refresh() call could cause global uncaught exceptions (perhaps NPEs).
> Any case where we .notify and .refresh are candidates for UI instability
> if the user changed the page.
>
> After the conversation I am more convinced that explicit page
> transitions should drop all async responses related to previous pages.
>
> I am going to mock this up and put this onto the branch for review and
> testing. But I will also investigate options on how to .notify on "old"
> events w/o refreshing; but the purpose would be to cite options, not to
> implement them. They could be implemented if users complain. There are
> 175 locations in the code base that would be modified to support this.
>
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/rhq-devel
> _______________________________________________
> 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