how to show a "please wait" prompt

[csillag]

Is there a built-in way to tell the user to wait for some arbitrary process, just like all datasource operations do it? (I could display a dialog myself, but if it's already prepared for me, I would rather not duplicate this.)

[davidj6]

Try com.smartgwt.client.util.SC.showPrompt/clearPrompt.

[csillag]

That's exactly what I had in mind; just did not found the method.
Thank you!

[csillag]

That's exactly what I had in mind;

Well, almost, but not exactly.

The problem is the following:

Lets suppose there are two slow, async processes, which happen in the following order:

process A starts
process B starts
process A ends
process B ends


Now when process A ends, end calls clearPrompt(), there will be no indication of the fact that process B is still running. If it has displayed anything with showPrompt, the result is hidden.

The solution to this would be to have a central "process registry" manage this prompt. This way, when something slow starts, it could register with this register. If there is no prompt shown, a new prompt could be displayed, or if there is already one, content could be added to it. When a process end, the registry would now if that was the last, so the dialog can be hidden, or there is more, so only some content needs to be removed from the dialog.

Does such mechanism exist in SmartGWT?

[svjard]

Well SmartGWT has callbacks for data arrived and all, but I am guessing these are your own async processes, in which case short answer is no. Google Code have projects that have done this though, not too hard to implement.

[Isomorphic]

SmartGWT does this kind of tracking internally for RPCs. It's just a simple count of outstanding requests, easy to implement on your own.

[csillag]

Of course I can implement something like this on my own, the question is how do I integrate in with what is already in place. (I do not think it would be acceptable if two different dialogs nagged the user about the same thing, sometimes simultaneously..)

I can see two approaches:

1. I somehow register my own slow processes with the already existing internal tracker which SmartGWT uses to track RPCs, which in turn shows/hides the prompt appropriately.
To do this, I need an API for the internal tracker.

2. I implement my own tracker, and somehow make the RPC events (either individually, either collectively) register themselves on it, and my own tracked handles the prompt.
To do this, I need and API to redirect the default prompt mechanism.

Which one do you think would be the more practical? (I would vote for approach one, but I do not know what policies do you have in mind.)

[Isomorphic]

The second. There aren't APIs for hooking into the RPCManager's use of the prompt, and it's not clear it would be a good idea either, so this is why we were saying it's easy to implement your own.

[csillag]

OK, but then I need a way to make the DS operation prompts (which would be displayed by RPCs) go via my tracker, instead of going directly to the screen.

How can I do that?

[Isomorphic]

Sorry, not sure what "tracker" your talking about.

Is there some reason you don't just use showPrompt and hidePrompt and ignore the RPC system?

[csillag]

OK, so I will explain it once again, beginning with the basics.

* * *

In an application, there might be several background processes which need to block the UI sometimes. Naturally, the user would like to know what is going on (or at least that something is happening), so we would like to show a dialog box explaining the reason why he has to wait.

We have a showPrompt method and a clearPrompt method.

The first approach would be to just call showPromp when starting something slow, and hidePrompt when finishing it.

But if we have two overlapping processes, this method fails, because the process that finishes first hides the prompt, even if there are other processes which are not ready yet.

Therefore, we need to manage the showing/hiding prompt by one component. Call this a tracker, a manger, a registry, whatever you want.

If we have a tracker, we can do this: when a slow process starts, it tells the tracker that it's starting, so that the tracker can show a dialog (if not shown), or add the info to the currently shown dialog. When the process finishes, it tells the tracker that it has finished, so that the tracker can remove the info from the dialog, and hide the dialog if this was the last process.

So the second approach would be to implement and use such tracker component, but this only works while each and every background process uses the same tracker component for displaying this information.

But if somebody calls showPrompt (or, even worse, clearPrompt) independently, it will break the system, since it will overwrite (in case of showPrompt) or hide (in case of clearPrompt) the information about other running processes.

(If I ignore the RPC calls, the prompt shown by the RPC calls would overwrite my prompt showing other status, and when RPC calls are ready, and they call clearPrompt, they would hide the displayed information about other processes.)

Therefore, to get meaningful information, I need to channel all such information into one channel.

This brings us to the third approach: we need a tracker, and we need to make all DS and non-DS related slow processes to use this tracker.

To do this, I must be (at least) able to redirect the prompts that would be created as indicators of background DS processes.

This is where I am now.

* * *

Frankly, I think all this is pretty much straightforward and self-evident, and I do not really understand why I need to explain this in detail.

[Isomorphic]

Yes, we get the use case, it looks like the miscommunication was that we said "use showPrompt/clearPrompt" whereas yes, if your blocking operations are potentially *concurrent* with RPCs, you will need your own version of the "prompt" dialog rather than trying to share the one used by the RPCManager.

If you are worried about matching the appearance perfectly, use the Watch tab to look at the structure of the prompt - it's a pretty trivial combination of a Label inside of a modal Window.

However, what are these long-running, non-RPC related operations you're dealing with? You do realize that you only have a budget of about 5 million JavaScript instructions in IE before a "script running slowly" dialog appears, which is less than one second execution time on a modern machine? If you are doing substantive calculations client-side, you need to break it up with timers.

[csillag]

I am not worried about matching the appearance perfectly; I am worried about the possibility that the user being harassed by two different dialog boxes about the same thing, simultaneously.

Therefore, my point is not that I want a dialog box just like yours; it's that I want to channel all the prompts (both DS-related and independant) into _one_ dialog box.

If I don't do that, there would be times when two different prompt are shown simultaneously - either on different parts of the screen, or overlapping - none of these options make sense.

* * *

To answer your question about the processes:

One group of these are higher-level logical processes which encompass multiple DS operations (and thus wait for results), along with custom server calls. These could be partially handled by simply showing the built-in prompt, but
- it does not make sense to repeatedly hide and show the prompt, when all that is happening is part of one big operation, and
- I might want to hide the details, or at least present the higher-level description of the process, besides the details.

So I want to show a prompt for the "mother" operation, and ideally, the details of the DS sub-operations should also appear here.

The other group of processes is creating various GUI elements, or performing GUI adjustments (hiding and reordering fields in ListGrids, drawing custom JS graphics, updating the contents of GWT FlexTables, etc.)

[Isomorphic]

If the prompt is in the same place and appears the same, the user will never know there are two prompts involved.

For combining multiple RPCs into one blocking operation with a single prompt, use queuing (RPCManager.startQueue()).

Not that if you have a GUI operation that you feel the need to show a prompt for, you need to show the prompt then use a DeferredCommand before proceeding with the drawing you want to do. Otherwise in most cases the prompt will not appear until all drawing is done. This is a native browser behavior.