return false from ajax

Discussion in 'Javascript' started by Andrew Koptyaev, Apr 10, 2010.

  1. Hi

    I need to test input data from form by php (some mysql) after submit
    form. I use onclick event of submit button and run in onclick function
    sync jquery ajax get to server php. I know if I want come back to form
    I should return false. But I cant return false from success ajax function.

    Is exist solution to come back to form not submit.

    Thank you!

    Andrew.
    Andrew Koptyaev, Apr 10, 2010
    #1
    1. Advertising

  2. Andrew Koptyaev

    Sean Kinsey Guest

    On Apr 10, 7:24 pm, "Andrew Koptyaev" <> wrote:
    > Hi
    >
    > I need to test input data from form by php (some mysql) after submit
    > form. I use onclick event of submit button and run in onclick function
    > sync jquery ajax get to server php. I know if I want come back to form
    > I should return false. But I cant return false from success ajax function..
    >
    > Is exist solution to come back to form not submit.
    >
    > Thank you!
    >
    > Andrew.


    In stead of running the xhr in the onclick event, run a regular
    asynchronous call instead and return false to stop the submit.
    Then when the xhr finishes you either submit the form using js or show
    some feedback about what was wrong.
    Sean Kinsey, Apr 10, 2010
    #2
    1. Advertising

  3. > In stead of running the xhr in the onclick event, run a regular
    > asynchronous call instead and return false to stop the submit.
    > Then when the xhr finishes you either submit the form using js or show
    > some feedback about what was wrong.


    Thank you.
    But in my config if do on submit onclick="return false;" then submit button
    not working as expected.

    If I do like onclick="checkForm();"
    where:
    function checkForm(){
    return false;
    }
    then my form submit as not expected.

    weird.

    --
    http://luvz.ru
    Andrew Koptyaev, Apr 10, 2010
    #3
  4. sorry for the link in the footer

    sorry for the link in the footer
    Andrew Koptyaev, Apr 10, 2010
    #4
  5. Andrew Koptyaev

    Sean Kinsey Guest

    On Apr 10, 10:06 pm, "Andrew Koptyaev" <> wrote:
    > > In stead of running the xhr in the onclick event, run a regular
    > > asynchronous call instead and return false to stop the submit.
    > > Then when the xhr finishes you either submit the form using js or show
    > > some feedback about what was wrong.

    >
    > Thank you.
    > But in my config if do on submit onclick="return false;" then submit button
    > not working as expected.
    >
    > If I do like onclick="checkForm();"
    > where:
    > function checkForm(){
    > return false;}
    >
    > then my form submit as not expected.
    >
    > weird.


    Not weird at all.

    its either
    onclick="return false;"
    or
    onclick="return checkForm();"
    where checkform = function(){return false;}
    Sean Kinsey, Apr 10, 2010
    #5

  6. > its either
    > onclick="return false;"
    > or
    > onclick="return checkForm();"
    > where checkform = function(){return false;}
    >

    That is true.
    But question regarding submit from JavaScript.

    If I do document.myForm.submit() then I got php script in my URL
    and no anything on screen . This php script is form "myForm" action.

    If I try to document.getElementById("myInput").submit() where
    myInput is input with submit button
    then got document.getElementById("myImput").submit is not a function

    what is the solution?
    Andrew Koptyaev, Apr 11, 2010
    #6
  7. > If I try to document.getElementById("myInput").submit() where
    > myInput is input with submit button
    > then got document.getElementById("myImput").submit is not a function
    >
    > what is the solution?


    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

    fix error but still not working
    Andrew Koptyaev, Apr 11, 2010
    #7
  8. Andrew Koptyaev

    VK Guest

    On Apr 11, 1:10 pm, "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". NEVER ever do it. The best of all: forget that input[submit]
    has name or id attribute: unless forced to deal with multiple submit
    buttons.

    <form action="your.php" onsubmit="validate(this); return false;">
    ....
    <input type="submit">
    </form>

    function validate(frm) {
    // if frm input server-side sync check OK then:
    // frm.submit();
    //
    // On programmatic submit() form onsubmit handler
    // is not called
    }

    Of course AJAX call has to be synced and of course it is very bad is
    server-side check may tack a noticeable amount of time: for user it
    will be like the browser became frozen on submit click.

    To make it really usable you need to break it on blocks and allow
    screen refresh, something like:

    <form action="your.php" onsubmit="return validate(this);">
    ....
    <input type="submit">
    </form>

    function validate(frm) {
    // show "checking" message
    // or any visual signal that something
    // is going on but may take time

    // release context so the page could be updated:
    window.setTimeout(validate2(frm), 10);

    return false;
    }

    function validate2(frm) {
    // do AJAX data check
    // if frm input server-side sync check OK then:
    // frm.submit();
    //
    // On programmatic submit() form onsubmit handler
    // is not called
    }

    etc.
    VK, Apr 11, 2010
    #8
  9. Andrew Koptyaev

    Sean Kinsey Guest

    On Apr 11, 3:15 pm, VK <> wrote:
    > On Apr 11, 1:10 pm, "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".


    I can see nothing to support that statement.
    The reason is that the input element has not submit method, only the
    form.

    > NEVER ever do it. The best of all: forget that input[submit]
    > has name or id attribute: unless forced to deal with multiple submit
    > buttons.
    >
    > <form action="your.php" onsubmit="validate(this); return false;">
    > ...
    >  <input type="submit">
    > </form>
    >
    > function validate(frm) {
    >  // if frm input server-side sync check OK then:
    >  // frm.submit();
    >  //
    >  // On programmatic submit() form onsubmit handler
    >  // is not called
    >
    > }
    >
    > Of course AJAX call has to be synced and of course it is very bad is
    > server-side check may tack a noticeable amount of time: for user it
    > will be like the browser became frozen on submit click.


    There is no reason to use a synchronous call here.

    >
    > To make it really usable you need to break it on blocks and allow
    > screen refresh, something like:
    >
    > <form action="your.php" onsubmit="return validate(this);">
    > ...
    >  <input type="submit">
    > </form>
    >
    > function validate(frm) {
    >  // show "checking" message
    >  // or any visual signal that something
    >  // is going on but may take time
    >
    >  // release context so the page could be updated:
    >  window.setTimeout(validate2(frm), 10);


    This is an error, its either 'setTimeout("validate2(frm);",10);' which
    is bad as it uses eval and thus runs only in the global scope,
    or 'setTimeout(function(){validate2(frm);},10)'
    Either way, its not needed if you just start an async operation
    Sean Kinsey, Apr 11, 2010
    #9
  10. Andrew Koptyaev

    VK Guest

    > > That is because you named or id'ed your submit button "Submit" or
    > > "submit".

    >
    > I can see nothing to support that statement.
    > The reason is that the input element has not submit method, only the
    > form.


    Very true? and that's the point :) Now try this:

    <form action="">
    <input type="submit" name="submit" value="Submit">
    </form>

    and now document.forms[0].submit() or any variants. A very old DHTML
    oops, never fixed.


    > > NEVER ever do it. The best of all: forget that input[submit]
    > > has name or id attribute: unless forced to deal with multiple submit
    > > buttons.

    >
    > > <form action="your.php" onsubmit="validate(this); return false;">
    > > ...
    > >  <input type="submit">
    > > </form>

    >
    > > function validate(frm) {
    > >  // if frm input server-side sync check OK then:
    > >  // frm.submit();
    > >  //
    > >  // On programmatic submit() form onsubmit handler
    > >  // is not called

    >
    > > }

    >
    > > Of course AJAX call has to be synced and of course it is very bad is
    > > server-side check may tack a noticeable amount of time: for user it
    > > will be like the browser became frozen on submit click.

    >
    > There is no reason to use a synchronous call here.


    There is a very good one. Otherwise the AJAX check request will be
    sent and - right after - the form submitted without waiting check
    results.

    > > To make it really usable you need to break it on blocks and allow
    > > screen refresh, something like:

    >
    > > <form action="your.php" onsubmit="return validate(this);">
    > > ...
    > >  <input type="submit">
    > > </form>

    >
    > > function validate(frm) {
    > >  // show "checking" message
    > >  // or any visual signal that something
    > >  // is going on but may take time

    >
    > >  // release context so the page could be updated:
    > >  window.setTimeout(validate2(frm), 10);

    >
    > This is an error, its either 'setTimeout("validate2(frm);",10);' which
    > is bad as it uses eval and thus runs only in the global scope,
    > or 'setTimeout(function(){validate2(frm);},10)'
    > Either way, its not needed if you just start an async operation


    The latter one, right. My typo? thank you for correcting.
    VK, Apr 11, 2010
    #10
  11. Andrew Koptyaev

    Sean Kinsey Guest

    On Apr 11, 3:41 pm, VK <> 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.

    <snip>
    > The latter one, right. My typo? thank you for correcting.


    Whats up with the question mark?
    Sean Kinsey, Apr 11, 2010
    #11
  12. Andrew Koptyaev

    VK Guest

    On Apr 11, 5:53 pm, Sean Kinsey <> wrote:
    > On Apr 11, 3:41 pm, VK <> 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)
    VK, Apr 11, 2010
    #12
  13. Andrew Koptyaev

    Sean Kinsey Guest

    On Apr 11, 4:15 pm, VK <> wrote:
    > On Apr 11, 5:53 pm, Sean Kinsey <> wrote:
    >
    > > On Apr 11, 3:41 pm, VK <> 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.
    Sean Kinsey, Apr 11, 2010
    #13
  14. Andrew Koptyaev

    VK Guest

    On Apr 11, 6:22 pm, Sean Kinsey <> wrote:
    > On Apr 11, 4:15 pm, VK <> wrote:
    >
    >
    >
    > > On Apr 11, 5:53 pm, Sean Kinsey <> wrote:

    >
    > > > On Apr 11, 3:41 pm, VK <> 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.
    VK, Apr 11, 2010
    #14
  15. 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$>
    Thomas 'PointedEars' Lahn, Apr 12, 2010
    #15
  16. VK wrote:

    >> > That is because you named or id'ed your submit button "Submit" or
    >> > "submit".

    >>
    >> I can see nothing to support that statement.
    >> The reason is that the input element has not submit method, only the
    >> form.

    >
    > Very true? and that's the point :) Now try this:
    >
    > <form action="">
    > <input type="submit" name="submit" value="Submit">
    > </form>
    >
    > and now document.forms[0].submit() or any variants. A very old DHTML
    > oops, never fixed.


    Nobody ever called document.forms[0].submit() here in the first place.

    When will you have learned to quote?


    PointedEars
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
    Thomas 'PointedEars' Lahn, Apr 12, 2010
    #16
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. André
    Replies:
    3
    Views:
    1,584
  2. Rajarshi

    0 == False but [] != False?

    Rajarshi, May 24, 2007, in forum: Python
    Replies:
    20
    Views:
    703
    Erik Max Francis
    May 30, 2007
  3. w i l l
    Replies:
    4
    Views:
    234
    Dan Brussee
    Jul 4, 2003
  4. Replies:
    1
    Views:
    434
    Randy Webb
    Oct 6, 2005
  5. Replies:
    10
    Views:
    307
    Thomas 'PointedEars' Lahn
    Feb 16, 2006
Loading...

Share This Page