public void doSomething(String href)
{
/*
* At this point you program is trolling along doing things that don't
* rely on the response here (like creating the page structure), working
* out what the href is going to be etc.
*
* Then you want to request the data
*
* You would be better off switching to RequestBuilder. Here's an
* example. This sends off the request.
*/
try
{
RequestBuilder builder = new RequestBuilder(RequestBuilder.GET, href);
builder.setHeader("Content-Type", "application/x-www-form-urlencoded");
/*
* The callback is where the processing of this request will pick up
* again when the server responds.
*/
builder.sendRequest(null, callback);
}
catch (RequestException e)
{
/*
* The request failed on the client without being sent
*/
Window.alert("RequestException: " + e.getMessage());
}
/*
* The request has been made but the data isn't available. In a
* synchronous call, you'd have the data, in this async one, you don't.
*
* If you were phoning a big company, you'd be listening to calming
* music and be getting told that your call is important to them.
*
* In a synchronous telephone call, you just close your eyes and wait
* for the call to be answered. In an async telephone call, you put it
* on the speakerphone and get on with your game of Spider, chat to your
* colleague, stare out the window, drink your coffee, and so on. You
* might even do a bit of work.
*
* In a synchronous call, you block the thread. That doesn't matter if
* you have more than one thread. In JavaScript, you don't. With async
* calls, timers, and deferred commands, you are emulating threading.
* Each request is a path which will continue again when it is ready and
* has control again.
*
* You can send off more than one request, and then you have, say, two
* more 'threads', two more paths to be followed. In this case, remember
* that, like waiting for two on-hold calls to be answered, you can't
* tell which one will be answered first, so in the second callback,
* don't assume the first callback has run.
*
* Any code you put here means that you are using what would otherwise
* be dead time waiting for a response. Just don't forget that you don't
* have the data yet. Even if the call is lightening-fast and you are
* doing shed-loads of heavy processing here, the onResponseReceived is
* still queued and will only run after this code has finished.
*/
}
//===================================
/*
* This callback gets called when the request returns - both on success and
* failure
*/
RequestCallback callback = new RequestCallback()
{
public void onError(Request request, Throwable e)
{
/*
* The request failed really badly on the server. This more than the
* 'expected' failures like a 404 and more serious than a 12017
* ('The operation was cancelled, usually because the handle on
* which the request was operating was closed before the operation
* completed')
*
* This is something really bad. I've never seen one. Well, I've
* never knowingly caught one.
*/
Window.alert("onError Error: " + e.getMessage());
}
//===================================
public void onResponseReceived(Request request, Response response)
{
/*
* The request was dealt with properly by the server, even if the
* server's response was a '404: Page Not Found' or worse - so you
* still need to check the return code
*/
if(response.getStatusCode() != 200)
{
Window.alert("onResponseReceived Error: " + response.getStatusText());
return;
}
/*
* At this point, all you know is that you successfully got a string
* back. It is whatever your server-side program sent back. Bear in
* mind that this might be a MySQL error or a PHP syntax error
* message. Success is relative.
*
* Anyway, send the text off to be dealt with.
*/
doThingsWithTheData(response.getText());
}
};
//===================================
public void doThingsWithTheData(String dataString)
{
/*
* Now you have the data, or a PHP error message, or a null, or
* something. But...
*
* a) The request got sent
*
* b) The server didn't blow up
*
* c) Your page was there
*
* d) Some string (or a null) was returned by your server-side page.
*
* Here you can carry on with all the code you would have had after the
* synchronous call. It's no different, you still waited for the call to
* return, but instead of locking up the browser, users have been able
* to do things in the mean time - switch tabs, watch your stock ticker
* etc, and any other code waiting to run (timers, deferred commands
* etc) has had the chance to do its thing.
*/
}
--
Ian
http://examples.roughian.com
___________________________________
Life is either a daring adventure or nothing.
Security is mostly a superstition.
It does not exist in nature.
- Helen Keller
___________________________________
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
