return false from ajax

[Andrew Koptyaev]

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.

 

[Sean Kinsey]

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.

 

[Andrew Koptyaev]

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.

 

[Andrew Koptyaev]

sorry for the link in the footer

 

[Sean Kinsey]

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;}

 

[Andrew Koptyaev]

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]

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

 

[VK]

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.

 

[Sean Kinsey]

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

 

[VK]

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

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.

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.

 

[Sean Kinsey]

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.

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

Whats up with the question mark?

 

[VK]

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

Whats up with the question mark?

Suppose to be , (comma)

 

[Sean Kinsey]

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.

 

[VK]

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.

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.

 

[Thomas 'PointedEars' Lahn]

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

 

[Thomas 'PointedEars' Lahn]

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