I wrote a loading mask that creates a transparent mask over the window
to stop input. After a second or two an animated loading message fades
into view. That way if the request is quick you don't get a message
flashing on and off.
On Jul 21, 3:36 pm, cokol wrote:
> ...in that case it would be an
...in that case it would be an option to show up a modal dialog asking
the user to get some coffee :-)
@mk
youre welcome!
On 21 Jul., 20:20, Brian Reilly wrote:
> Could you get the same effect by preventing user input during your
> server request, either by finding all of the controls/links and
Could you get the same effect by preventing user input during your
server request, either by finding all of the controls/links and
disabling them or overlaying something that receives and swallows all
events? At least that way, you're not locking up the browser
completely. Is there some other funct
Don't get me wrong... I'm about as opposed to synchronous requests as
everyone else... I'm just saying that in some cases it might be
justifiable.
On Jul 21, 10:32 am, mk wrote:
> Thanks cokol for A+ responses.
>
> On Jul 21, 10:10 am, cokol wrote:
>
>
>
> > I see, i think google just did not wa
Thanks cokol for A+ responses.
On Jul 21, 10:10 am, cokol wrote:
> I see, i think google just did not want to make a tool which can be
> abused resulting in frustrated users :)
>
> but anyway, you can endeed get it simpler than just hacking JSNI from
> scratch - extend the XMLHttpRequest class
I see, i think google just did not want to make a tool which can be
abused resulting in frustrated users :)
but anyway, you can endeed get it simpler than just hacking JSNI from
scratch - extend the XMLHttpRequest class and add a new method open()
which flags the underlying connection as async (by
I understand that asynchronous is the way to go and sometimes we
change UI design just to support async. But atleast in our project,
there are functional requirements where sync is the only solution.
(BTW: sync is not as bad. I understand that javascript in browser is
single threaded but it's used
indeed it could be a valid use case; but not without a constraint,
just imagine I wanna close my browser and your sync onunload() request
would take 5 secs to be processed by server - what happens then? its
evil!
imho, if you want to process the response afterwards, like printing it
out to the use
On 21/07/10 16:10, Nathan Wells wrote:
> There is only one case I know of where synchronous should be used:
> when you want to do a server call and get a response when the user is
> leaving the page.
I sincerely hope that my web browser would fail to honour this! Delaying
page close is deeply anti
There is only one case I know of where synchronous should be used:
when you want to do a server call and get a response when the user is
leaving the page. If you don't use synchronous here, you will fail to
get the response from whatever asynchronous call you made when the
page exits.
On Jul 21, 8
It is strongly recommended to avoid using AJAX on synchronous way!
Remember that A in AJAX is for Asynchronous. So you should consider
and use this as a feature not as a problem.
Using AJAX on Synchronous way is a very common anti pattern in AJAX
programming.
On Jul 20, 9:09 pm, Prakash wrote:
>
Its not possible with GWT.
refer below link.
http://code.google.com/webtoolkit/doc/latest/FAQ_Server.html
Regards,
Prakash M.
On Jul 20, 10:06 am, mk wrote:
> How to make an GWT AJAX call Sync (instead of async)
>
> billion years back we used to use a flag as below. how to do it from
> GWT.
>
How to make an GWT AJAX call Sync (instead of async)
billion years back we used to use a flag as below. how to do it from
GWT.
AJAX.open("GET", url, false);
It's just that for a particular requirement we have to have call sync
--
You received this message because you are subscribed to the Goog
13 matches
Mail list logo
