<code>
public abstract class MyAsyncCallback<T> implements AsyncCallback<T> {
public final void onFailure(Throwable caught) {
if(caught instanceof StatusCodeException &&
((StatusCodeException)caught).getStatusCode() == 401) {
final LoginDialog login = new LoginDialog();
login.addLoginDialogListener(new LoginDialogListener() {
public void loginSuccess() {
login.hide();
//RESUBMIT THE ORIGINAL RPC HERE
}
});
} else {
Window.alert("An error has occurred. Contact your system
administrator.");
}
}
public final void onSuccess(T result) {
uponSuccess(result);
}
public abstract void uponSuccess(T result);
}
</code>
Does anybody know how I can capture the original RPC before it is sent
so I can resubmit it?
We ended up patching ProxyCreator (look up the class) to automatically
retry any requests with strange error codes (0, 12090, 400), and now
that I think about it, it would be nice to do this for session
timeouts as well.
It would be great if gwt could provide a mechanism to provide a custom
retry behavior as standard that applies globally, rather than having
to do it for every async method yourself. If anyone's interested in
collaborating on this let me know.
I suppose Ray Ryan's proposal to use a command pattern for your RPC
calls [1] would help you in solving it.
[1] http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html
> [1]http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPr...
On 8 fév, 18:15, Jamie <jsgreenb...@gmail.com> wrote:
> Can you give me an example on how I'd be able to resubmit an RPC with
> Ray's command pattern approach?
I cannot give you a working example, but you'd likely queue all issued
commands and only dequeue them onSuccess. When you think you have to
resubmit your commands, you just have to go through the queue. This is
because the command is "self descriptive": it contains all the
necessary information that's needed.
Ray explained that this same pattern also allows you to easily undo
commands (easily on the client side, of course) and to batch commands
to limit the number of requests sent to the server; not to mention
offline mode (you'd save commands in a localStorage or similar offline
storage so they can be submitted when you go back online)