return false from ajax
in [JavaScript]
|
Prev: FAQ Topic - Why doesn't the global variable "divId" always refer to the element with id="divId"? (2010-04-10)
Next: ECMA-262-3 in detail. Chapter 8. Evaluation strategy.
From: VK on 11 Apr 2010 10:15 On Apr 11, 5:53 pm, Sean Kinsey <okin...(a)gmail.com> wrote: > On Apr 11, 3:41 pm, VK <schools_r...(a)yahoo.com> wrote: > > > > > There is a very good one. Otherwise the AJAX check request will be > > sent and - right after - the form submitted without waiting check > > results. > > Nope, the 'return false;' statement will cancel the submit. Unless I misread OP's intentions, the desired sequence is: 1) user fills the form 2) user presses submit 3) form submission is placed on hold 4) some form data being checked server-side over AJAX call 5) upon check results: either submit the whole form using form.submit() or cancel the submission If it is right, then sync request, visual notices and per-function blocks are needed. If the simplified way is possible depends on the expected max server response. Then: 1) user fills the form 2) user presses submit 3) form submission is cancelled 4) some form data being checked server-side over async AJAX call 5) upon check results via the callback function: either submit the whole form using form.submit() or inform about the bad data and stop on it > <snip> > > > The latter one, right. My typo? thank you for correcting. > > Whats up with the question mark? Suppose to be , (comma)
From: Sean Kinsey on 11 Apr 2010 10:22 On Apr 11, 4:15 pm, VK <schools_r...(a)yahoo.com> wrote: > On Apr 11, 5:53 pm, Sean Kinsey <okin...(a)gmail.com> wrote: > > > On Apr 11, 3:41 pm, VK <schools_r...(a)yahoo.com> wrote: > > > > There is a very good one. Otherwise the AJAX check request will be > > > sent and - right after - the form submitted without waiting check > > > results. > > > Nope, the 'return false;' statement will cancel the submit. > > Unless I misread OP's intentions, the desired sequence is: > > 1) user fills the form > 2) user presses submit > 3) form submission is placed on hold > 4) some form data being checked server-side over AJAX call > 5) upon check results: > either submit the whole form using form.submit() > or cancel the submission > > If it is right, then sync request, visual notices and per-function > blocks are needed. If the simplified way is possible depends on the > expected max server response. Then: What do you mean by 'max server response'? > > 1) user fills the form > 2) user presses submit > 3) form submission is cancelled > 4) some form data being checked server-side over async AJAX call > 5) upon check results via the callback function: > either submit the whole form using form.submit() > or inform about the bad data and stop on it Both approaches are 100% identical except for one being blocking (sync) and one being non-blocking (async). There are very few reasons to prefer the first over the second, except for some crude way of ensuring that the user cannot interact with the document before the check has completed. So why you set the first as the desired one is lost to me.
From: VK on 11 Apr 2010 10:57 On Apr 11, 6:22 pm, Sean Kinsey <okin...(a)gmail.com> wrote: > On Apr 11, 4:15 pm, VK <schools_r...(a)yahoo.com> wrote: > > > > > On Apr 11, 5:53 pm, Sean Kinsey <okin...(a)gmail.com> wrote: > > > > On Apr 11, 3:41 pm, VK <schools_r...(a)yahoo.com> wrote: > > > > > There is a very good one. Otherwise the AJAX check request will be > > > > sent and - right after - the form submitted without waiting check > > > > results. > > > > Nope, the 'return false;' statement will cancel the submit. > > > Unless I misread OP's intentions, the desired sequence is: > > > 1) user fills the form > > 2) user presses submit > > 3) form submission is placed on hold > > 4) some form data being checked server-side over AJAX call > > 5) upon check results: > > either submit the whole form using form.submit() > > or cancel the submission > > > If it is right, then sync request, visual notices and per-function > > blocks are needed. If the simplified way is possible depends on the > > expected max server response. Then: > > What do you mean by 'max server response'? Maximum time before the request and the response lesser some FUBAR events like connection lost, computer shut down etc. It all depends on what and how going to be checked server side. It may be 100ms average up to 300-400ms in max. It may be up to a minute for a complex data check across several db server-side and 3rd party servers. It may be above the default connection life time (over 180 sec) for some really complex data gathering like say for a discount ticked booking system. In the latter case the whole approach has to be changed anyway, but I have a feeling that this is not a case here. > > 1) user fills the form > > 2) user presses submit > > 3) form submission is cancelled > > 4) some form data being checked server-side over async AJAX call > > 5) upon check results via the callback function: > > either submit the whole form using form.submit() > > or inform about the bad data and stop on it > > Both approaches are 100% identical except for one being blocking > (sync) and one being non-blocking (async). > There are very few reasons to prefer the first over the second, except > for some crude way of ensuring that the user cannot interact with the > document before the check has completed. So why you set the first as > the desired one is lost to me. Exactly for "crude way of ensuring that the user cannot interact". The golden rule of thumb of agood interface: the user is allowed to interact only when you want her to interact and only in the way you want her to interact. Any of her attempts to "improvise" or "to be impatient" have be very gently but firmly sent to the hell. It is my rule though, so either one of approaches are proposed to OP.
From: Stefan Weiss on 11 Apr 2010 19:27 On 11/04/10 16:57, VK wrote: > On Apr 11, 6:22 pm, Sean Kinsey <okin...(a)gmail.com> wrote: >> Both approaches are 100% identical except for one being blocking >> (sync) and one being non-blocking (async). >> There are very few reasons to prefer the first over the second, except >> for some crude way of ensuring that the user cannot interact with the >> document before the check has completed. So why you set the first as >> the desired one is lost to me. > > Exactly for "crude way of ensuring that the user cannot interact". The > golden rule of thumb of agood interface: the user is allowed to > interact only when you want her to interact and only in the way you > want her to interact. Any of her attempts to "improvise" or "to be > impatient" have be very gently but firmly sent to the hell. It is my > rule though, so either one of approaches are proposed to OP. Never heard of this golden rule, but whatever. The problem here is that the document containing the form is only one part of the whole interface. In addition to the browser UI, there may be other tabs and other windows - there's no reason why the users shouldn't interact with their browser or other documents just because one script is waiting for a server response. If you don't want the user to interact with *your* document while a request is pending, there are better ways to ensure that without locking up the whole browser. The asynchronous request is a much better alternative. -- stefan
From: Thomas 'PointedEars' Lahn on 11 Apr 2010 21:44
VK wrote: > "Andrew Koptyaev" wrote: >> If I try to document.getElementById("myInput").submit() where >> myInput is input with submit button >> then got document.getElementById("myInput").submit is not a function > > That is because you named or id'ed your submit button "Submit" or > "submit". No. `myInput' is clearly not the ID of a FORM element, and of DOM element objects only form objects (representing those elements) have a submit() method. That is why it does not work. > NEVER ever do it. That is true nevertheless, for a change. > The best of all: forget that input[submit] has name or id attribute: > unless forced to deal with multiple submit buttons. Here's your usual clueless nonsense again. > > <form action="your.php" onsubmit="validate(this); return false;"> > ... > <input type="submit"> And what if they needed the ID for CSS? Or as an anchor? > [snip nonsense about "syncing AJAX calls"] PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk> |