This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Line 43 specifies that your call will be asynchronous (by specifying "true" as the last parameter):
With this in place, in your "def" function, at line 53 you will call the Ajax function, which will send a request to the server, and without waiting for a response it will then continue with the remainder of the "def" function. Since there has been no response received yet, "res" will not have the response from the server, so you are almost certainly going to go on to the else statement in line 59. It is then just a matter of luck when the response is received - I suspect that the "two clicks" is more just the amount of time it takes you to click multiple times gives the server time to return the response.
Also, please check your private messages regarding an important administrative matter.
Do you mean to say that I have to change the value true to false?
Because the request may not have been processed in the servlet or is it so?
BTW, I've read from a link as follows:
Performance Note When Async is set to false, send operations are synchronous, and Windows Internet Explorer does not accept input or produce output while send operations are in progress. Therefore, this setting should not be used in situations where it is possible for a user to be waiting on the send operation to complete.
I obviously don't understand these terminologies, synchronous and asynchronous since in my case its just I have to wait for the response to complete from the server end.
author and jackaroo
Don't worry, the terminology will get easy soon enough.
In an asynchronous request, the request / response is completely separate from how the main browser logic is working. So you can continue doing other work in the browser while waiting to get the response back (including clicking the button multiple times).
In a synchronous request, everything must happen in the order you specified, and it is only when one event has completed that the system is considered synchronized and can move on to the next task. Hence the comment that the browser can appear completely unresponsive while waiting for a response to come back.
Again, the note you mentioned is correct: generally speaking, anytime you force the user into a situation where they have no clue what is going on, and a system that appears to be dead, you risk them simply closing that system. This is a really bad user experience and should be avoided.
Normally I would recommend against using Ajax in a login screen - when you get the response back from the server (stating that the login was successful), you are presumably going to redirect to another screen. So you are effectively making the user wait for twice the length of time needed for roundtrip communications with the server.
However on the assumption that this is desirable for some reason, then I would approach it completely differently.
I would have the "def" function disable the login button until a response has been received. And I would have it always return false.
I would then have the "handleServerResponse" function check for whether the response was "y", and if it was, perform the form submission / redirection / whatever else is needed. If the response was not "y" then it would show the error message and re-enable the login button.
This problem got solved.
I thought of reusing the ajaxFunction(url) but since I have to make response text a global variable, the function moves on to the next sequence only when the xmlhttp.status is changed. So, it has to wait until all other requests has been answered in the servlet.
My answer of reusing the function is a big "NO". So, i made smaller changes in the servlet and by rearranging the code by placing all the conditions to verify the response text after this:
So, after my experience of reusing this response method, the answer is pretty simple: "verify the response text asap!!!".