Progress indicator
Vik
Thomas Broyer
On Mar 28, 6:49 pm, Vik <vik....@gmail.com> wrote:
> Hie
>
> In my gwt app when i hit say submit button in a form it takes a while to get
> the response from server.
> Currently it seems nothing is happened on clicking the button.
>
> So how to show some kind of indicator showing its in progress?
You can show something (a label, a popup, an animated GIF image, etc.)
in onSubmit and hide it in onSubmitComplete; but you won't be able to
show "progress".
Vik
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Yogesh
Check the comments posted by Srini Marreddy here:
http://groups.google.com/group/google-web-toolkit/browse_thread/thread/e315c7532c2ff111/4767d65461deb9fd?lnk=gst&q=progress+bar#4767d65461deb9fd
I think that is what you are looking for.
Regards,
Yogesh
> > google-web-tool...@googlegroups.com<google-web-toolkit%2Bunsubs cr...@googlegroups.com>
VladS
http://www.ajaxload.info
then you can modify rotation speed in other editor.
VladS
colors and types.
google do not allow me to post it to forum because of the info domain
VladS
generator.
spacejunkie
calls and fire events.
Such global events can be used to display or hide busy indicators.
Writing code for busy indicator for each async call creates clutter.
Besides if the same busy indicator is
shared by multiple async calls, one has to write additional logic to
handle concurrent async calls -
for example if one call finishes but other is still in progress and if
the callback simply hides the indicator then the first callback would
hide the indicator and mislead the user into believing that all
processes are complete.
The state of each call has to be monitored in this case. This isn't
too difficult, but having to replicate same code in every call doesn't
feel right.
There should be an event or some hook into GWT internals that can tell
if any async call is in progress.
I would like to hear some thoughts on this.
I have searched a lot and haven't found any API support to do this.
This is a big feature missing in GWT.
If I'm missing out something please point out.
Regards,
Priyank
kozura
can be solved universally. That one or more RPC calls are in progress
does not imply necessarily that a waiting dialog should be showing.
For example say I have a page with several panels that each separately
make an RPC call to fetch some data. If one comes back, why not fill
it and allow the user to interact with it while the others still
load? No need to freeze the whole app. In this case, maybe each
panel can have a "Loading..." message that gets changed to good GUI
stuff once the data arrives.
That said, it's fairly easy to create your own generic class that can
bring up a wait dialog when you do need to wait for something; I have
one for my runAsync calls because when I'm waiting for code to load I
really don't want any other interaction. You just call to create it
before your RPC/runAsync call, and then to remove it on onSuccess and
onFailure. Better still is to have a cancel button on it which can be
checked and handled in onSuccess. But I'd be leery trying to make one
work automatically for all calls, as you are unnecessarily crippling
your user experience.
spacejunkie
> before your RPC/runAsync call, and then to remove it on onSuccess and
> onFailure
Yes, that's how its done and I'm doing it more or less the same way.
Consider this example:
You have several components in a panel, each of which can trigger an
async call. You want to activate a shared busy indicator for any async
activity.
You are forced to write the same code in many places. Doing this is
not a big task but maintaining it would be tedious, sooner or later,
inconsistencies would crop up. So the point is to do it in a single
place just once...or once per each logical component.
> That one or more RPC calls are in progress
> does not imply necessarily that a waiting dialog should be showing.
Agree. I wasn't talking about having GWT display the loading
indicator.
But some event capturing mechanism that could be applied like an
aspect if one wanted.
I was talking about getting access to async call status and events by
registering in a single place.
Instead of having to write additional code in 2 places for each call
just to be able to catch the events.
If we could get these events or be able query gwt about status of
calls
made through its RPC mechanism, it would simplify many use cases.
Thanks for your comments.
Regards,
Priyank
kozura
centralized event/query system would simplify this in most apps.
Let's say there's an events for every call and completion of RPCs, and
for some RPCs there needs to be a wait dialog - the usual case. Now
we still need code, now in one function, to decide whether a
particular RPC requires the dialog. Still need code to remember
whether other dialog-requiring calls are pending. Need some new way
to pass determine in the event which RPC we're referring to, to even
make this decision. And now I have to maintain code for how to deal
with particular calls in 2 places, where the RPC is called and in this
central event handler. So really the only case where this is a
simpler solution is when we don't care about all of that and just
bring up the same waiting dialog during every RPC call.
Whereas with a single well designed class of your own, all the code is
in one place except the calls to open/close it. In fact with a bit
more cleverness you can incorporate the AsyncCallbackHandler into it
so that the closing gets handled automatically, perhaps even with a
Cancel button that would call your onFailure instead of onSuccess if
the user canceled. Then you only have a single extra piece of code,
used only on the RPCs where you want the dialog, something like:
rpcService.myRPCCall(String argument, new WaitingDialog(new
myAsyncCallback()));
WaitingDialog maintains a list of pending calls, implements
AsyncCallback, and handles the incoming onSuccess/Failure calls before
passing them to your own.
spacejunkie
AsyncCallback<T> {
private static int busy;
public final void onFailure(Throwable caught) {
GWT.log("RPC -> onFailure() - " + caught.getMessage());
doOnFailure(caught);
}
public final void onSuccess(T result) {
GWT.log("RPC -> onSuccess()");
doOnSuccess(result);
}
public void doOnFailure(Throwable caught) {
}
public abstract void doOnSuccess(T result);
}
This takes care of intercepting response events. Common functionality
goes into onSuccess and onFailure.
This can't be done for request events because call to any RPC service
goes directly to server and there's no hook to intercept these calls
before GWT sends it to the server.
------------------------
Consider this:
public interface RpcEventListener<T> extends AsyncCallback<T> {
public void onRequest();
}
Objects of this interface would be passed to the async service call.
GWT would check if the the object is an instance of this interface and
call onRequest().
That's it! That's all the support one needs from GWT.
It could me made fine grained by including all events fired by
XMLHttpRequest. But event a single method would be enough for most
cases.
One can the write support classes like the abstract class above and
get the required functionality in one place.
Additionally, there could be some API to query GWT for active
requests.
public static Collection<AsyncCallback> GWT.getAsyncRequests()
The AsyncCallback or RpcEventListener objects may also hold metadata
about which logical component they were called from or the
conversation id etc.
That way one can get more information about each request from
individual object.
kozura
you'd have to convince! getAsyncRequests() is unlikely because GWT
would have to add extra code and maintain that collection for
information most wouldn't use, which is quite easy to maintain on your
own if you really need.
As for the RpcEventListener you mention, this isn't a central event
dispatch, but more like the sol'n I mentioned, something that you
include as part of the RPC call. The only difference is you want GWT
to call your callback if it implements this interface while mine just
makes that call as part of creating the callback object. Why create
an extra callback mechanism when you KNOW that the RPC is being called
- you're calling it! Just take the little class you show up top and
add the central dialog logic to its constructor or a factory method,
whatever suits your fancy, and you get the same functionality:
public class RPCWrapper<T> implements AsyncCallback<T> {
private static List<AsyncCallback> pending;
private AsyncCallback<T> cb;
public RPCWrapper(AsyncCallback<T> userCb) {
cb = userCb;
pending.add(userCb);
...open dialog, whatever...
}
public static List<AsyncCallback> getPendingRpcs() {return
pending;}
private void onReturn() {
pending.remove(cb);
if (pending.isEmpty()) { ...close dialog, whatever }
}
public final void onFailure(Throwable caught) {
onReturn();
GWT.log("RPC -> onFailure() - " +
caught.getMessage());
cb.onFailure(caught);
}
public final void onSuccess(T result) {
onReturn();
GWT.log("RPC -> onSuccess()");
cb.onSuccess(result);
}
}
rpcService.callMyRPC(String args, new RPCWrapper(new
myAsyncCallback());
And now you can add this to any existing RPC call without changing the
callback interface at all.
jk