How to exit a form validation function so that the form isn'tsubmitted

A

Andrew Falanga

HI,

Just a warning, I'm a javascript neophyte. I'm writing a function to
validate the contents of a form on a web page I'm developing. Since
I'm a neophyte, this function is quite simple at this time (in fact, I
don't even know if it totally works, I'm still debugging). However,
the first problem is that when an error is encountered, I get my alert
box, I press ok and then the form is submitted and the new data is
entered into the database (and it shouldn't be). Basically, this is
what I've got (without all of the form tags):

in the <head> section of the page:
<script type="text/javascript">
function CheckFormValues() {
var nullsPresent = false;
var npf = document.getElementById("NewPatientForm");
for(var i=0; i < npf.length; i++) {
if(npf.elements.nodeType == "textarea")
continue;

if(npf.elements.value == "") {
nullsPresent = true;
break;
}
}
if(nullsPresent) {
alert("No item on this form may be null (except comments)
\nPlease correct and resubmit");
return;
}

npf.submit();
}
</script>

Then, the submit button (in the form tags):
<input type=button onClick="CheckFormValues()" style="height:40px;font-
size:18px;" value="Submit New Patient" />


What do I need to have in the function to make this function exit so
the user fills in the null strings and then re-submits? As you can
see, I tried a "return;" before the call to nfp.submit(), but that
didn't work. It still submitted the data to the DB.

Thanks,
Andy
 
T

Trevor Lawrence

Andrew Falanga said:
HI,

Just a warning, I'm a javascript neophyte. I'm writing a function to
validate the contents of a form on a web page I'm developing. Since
I'm a neophyte, this function is quite simple at this time (in fact, I
don't even know if it totally works, I'm still debugging). However,
the first problem is that when an error is encountered, I get my alert
box, I press ok and then the form is submitted and the new data is
entered into the database (and it shouldn't be). Basically, this is
what I've got (without all of the form tags):

in the <head> section of the page:
<script type="text/javascript">
function CheckFormValues() {
var nullsPresent = false;
var npf = document.getElementById("NewPatientForm");
for(var i=0; i < npf.length; i++) {
if(npf.elements.nodeType == "textarea")
continue;

if(npf.elements.value == "") {
nullsPresent = true;
break;
}
}
if(nullsPresent) {
alert("No item on this form may be null (except comments)
\nPlease correct and resubmit");
return;
}

npf.submit();
}
</script>

Then, the submit button (in the form tags):
<input type=button onClick="CheckFormValues()" style="height:40px;font-
size:18px;" value="Submit New Patient" />


What do I need to have in the function to make this function exit so
the user fills in the null strings and then re-submits? As you can
see, I tried a "return;" before the call to nfp.submit(), but that
didn't work. It still submitted the data to the DB.

Thanks,
Andy
Click to expand...


Hi Andrew

No problem to me. I have learnt how to use JS, but as a programmer I never
did come to grips with object oriented languages, so I am still learning

I thought about confirm and prompt boxes refer:
http://www.w3schools.com/js/js_examples_3.asp Window Object

But, maybe you could try (not tested)
<script type="text/javascript">
var npf = document.getElementById("NewPatientForm"); // npf is global
function CheckFormValues() {
var nullsPresent = false;
for(var i=0; i < npf.length; i++) {
if(npf.elements.nodeType == "textarea")
continue;

if(npf.elements.value == "") {
nullsPresent = true;
break;
}
}
return nullsPresent;
}

if (CheckFormValues()) { // function returned true
alert("No item on this form may be null (except comments)
\nPlease correct and resubmit");
CheckFormValues();
}
else // OK
npf.submit();
</script>

The function might even work like this
function CheckFormValues() {
for(var i=0; i < npf.length; i++) {
if ( npf.elements.nodeType == "textarea" && npf.elements.value
== "" )
return true;
}
return false;
}
 
T

Trevor Lawrence

What he said.

That is, I gave a solution which should work, with Conrad's points added

--
Trevor Lawrence
Canberra
Web Site http://trevorl.mvps.org
Conrad Lender said:
Just a warning, I'm a javascript neophyte.
Click to expand...

No problem. I've put some recommendations in parentheses.
the first problem is that when an error is encountered, I get my alert
box, I press ok and then the form is submitted and the new data is
entered into the database (and it shouldn't be). ..
function CheckFormValues() {
Click to expand...

(It's considered good style in JS to start the names of functions with a
lower-case letter unless the function is intended as a constructor)
var nullsPresent = false;
var npf = document.getElementById("NewPatientForm");
for(var i=0; i < npf.length; i++) {
Click to expand...

(This will evaluate npf.length on every iteration. Since the length is
constant, this could be written more efficiently as:
for (var i = 0, len = npf.length; i < len; i++)
)
if(npf.elements.nodeType == "textarea")
continue;

if(npf.elements.value == "") {
Click to expand...


(Is a single space considered valid input?)
Then, the submit button (in the form tags):
<input type=button onClick="CheckFormValues()" style="height:40px;font-
size:18px;" value="Submit New Patient" />
Click to expand...

(That's not really a submit button (type="submit")).

You can avoid the default action of the button like this:

<input type="submit" onclick="return CheckFormValues()" ...>

In the validation function, return true/false. You may also want to pass
the form element directly; this will save you the getElementById() call:

function CheckFormValues(npr) { ...
..
<input ... onclick="return CheckFormValues(this.form)" ...>

HTH.


- Conrad
Click to expand...
 
R

RobG

Just a warning, I'm a javascript neophyte.
Click to expand...

No problem. I've put some recommendations in parentheses.


the first problem is that when an error is encountered, I get my alert
box, I press ok and then the form is submitted and the new data is
entered into the database (and it shouldn't be). ..
function CheckFormValues() {
Click to expand...

(It's considered good style in JS to start the names of functions with a
lower-case letter unless the function is intended as a constructor)
   var nullsPresent = false;
   var npf = document.getElementById("NewPatientForm");
   for(var i=0; i < npf.length; i++) {
Click to expand...

(This will evaluate npf.length on every iteration. Since the length is
constant, this could be written more efficiently as:
  for (var i = 0, len = npf.length; i < len; i++)
)
      if(npf.elements.nodeType == "textarea")
         continue;
Click to expand...

      if(npf.elements.value == "") {
Click to expand...


(Is a single space considered valid input?)
Then, the submit button (in the form tags):
<input type=button onClick="CheckFormValues()" style="height:40px;font-
size:18px;" value="Submit New Patient" />
Click to expand...
Click to expand...


This is the key to the OP's issues. Firstly, if the button is there
to submit the form, it should be a submit button (i.e. type="submit").

Secondly, the validation function should added as a listener to the
form's onsubmit handler, not to the button's onclick handler.

Finally, the onsubmit handler will return whatever value the function
returns, and the function should return false if it wants to cancel
the submit.

e.g.

<script ...>
function CheckFormValues() {
var passed = true;

// do tests, set passed to false if any fail

return passed;
}
</script>

<form ... onsubmit="return CheckFormValues();" ...>
<!-- form controls ... -->
(That's not really a submit button (type="submit")).

You can avoid the default action of the button like this:

  <input type="submit" onclick="return CheckFormValues()" ...>
Click to expand...

But it's not the button's default action that needs to be avoided,
it's the form's sumbit that needs to be cancelled.

In the validation function, return true/false. You may also want to pass
the form element directly; this will save you the getElementById() call:

  function CheckFormValues(npr) { ...
  ..
  <input ... onclick="return CheckFormValues(this.form)" ...>
Click to expand...

And if the form is submitted some other way (e.g. pressing enter in
IE) the validation function won't be called. Use the form's onsubmit
handler.
 
T

Trevor Lawrence

Actually come to think of it, my solution won't work, for quite a few
reasons. So using Conrad's changes, it is probably more like this

<script type="text/javascript">
function CheckFormValues(npf) { ...
for(var i=0, len= npf.length ; i < len; i++) {
if ( npf.elements.nodeType == "textarea"
&& npf.elements.value == "" ) // or other null values ??
return false;
}
return true;
}
</script>

<input type="submit" onclick="return CheckFormValues(this.form)" ...>


The function will return true if no nulls (however defined) are found; false
if there are. On the assumption that false is the value that cancels the
submit action, this should work.

--
Trevor Lawrence
Canberra
Web Site http://trevorl.mvps.org

Trevor Lawrence said:
What he said.

That is, I gave a solution which should work, with Conrad's points added

--
Trevor Lawrence
Canberra
Web Site http://trevorl.mvps.org
Conrad Lender said:
Just a warning, I'm a javascript neophyte.
Click to expand...

No problem. I've put some recommendations in parentheses.
the first problem is that when an error is encountered, I get my alert
box, I press ok and then the form is submitted and the new data is
entered into the database (and it shouldn't be). ..
function CheckFormValues() {
Click to expand...

(It's considered good style in JS to start the names of functions with a
lower-case letter unless the function is intended as a constructor)
var nullsPresent = false;
var npf = document.getElementById("NewPatientForm");
for(var i=0; i < npf.length; i++) {
Click to expand...

(This will evaluate npf.length on every iteration. Since the length is
constant, this could be written more efficiently as:
for (var i = 0, len = npf.length; i < len; i++)
)
if(npf.elements.nodeType == "textarea")
continue;

if(npf.elements.value == "") {
Click to expand...


(Is a single space considered valid input?)
Then, the submit button (in the form tags):
<input type=button onClick="CheckFormValues()" style="height:40px;font-
size:18px;" value="Submit New Patient" />
Click to expand...

(That's not really a submit button (type="submit")).

You can avoid the default action of the button like this:

<input type="submit" onclick="return CheckFormValues()" ...>

In the validation function, return true/false. You may also want to pass
the form element directly; this will save you the getElementById() call:

function CheckFormValues(npr) { ...
..
<input ... onclick="return CheckFormValues(this.form)" ...>

HTH.


- Conrad
Click to expand...
Click to expand...
 
G

Gregor Kofler

Conrad Lender meinte:
(This will evaluate npf.length on every iteration. Since the length is
constant, this could be written more efficiently as:
for (var i = 0, len = npf.length; i < len; i++)
)
Click to expand...

Erm... gEBI() returns one *element*. Impossible to iterate through that.

Gregor
 
T

The Natural Philosopher

RobG said:
Just a warning, I'm a javascript neophyte.
Click to expand...
No problem. I've put some recommendations in parentheses.


the first problem is that when an error is encountered, I get my alert
box, I press ok and then the form is submitted and the new data is
entered into the database (and it shouldn't be). ..
function CheckFormValues() {
Click to expand...
(It's considered good style in JS to start the names of functions with a
lower-case letter unless the function is intended as a constructor)
var nullsPresent = false;
var npf = document.getElementById("NewPatientForm");
for(var i=0; i < npf.length; i++) {
Click to expand...
(This will evaluate npf.length on every iteration. Since the length is
constant, this could be written more efficiently as:
for (var i = 0, len = npf.length; i < len; i++)
)
if(npf.elements.nodeType == "textarea")
continue;
if(npf.elements.value == "") {
Click to expand...

(Is a single space considered valid input?)
Then, the submit button (in the form tags):
<input type=button onClick="CheckFormValues()" style="height:40px;font-
size:18px;" value="Submit New Patient" />
Click to expand...
Click to expand...


This is the key to the OP's issues. Firstly, if the button is there
to submit the form, it should be a submit button (i.e. type="submit").

Secondly, the validation function should added as a listener to the
form's onsubmit handler, not to the button's onclick handler.

Finally, the onsubmit handler will return whatever value the function
returns, and the function should return false if it wants to cancel
the submit.
Click to expand...


That's one way.

I did this another way.

The submit button isn't a submit button, its a generic button that
calls, on click, a javascript function that does the following
- validates.
- if validation fails, pops up an alert
- if validations pases, executes document.forms[0].submit();



In case its useful, here is the relevant stuff

*** style sheet *****************************

..button1

{
background-image: url("../Images/Button2.gif");
background-repeat: no-repeat;
background-position: center center;
text-align: center;
cursor:default;
font-size: 9px;
color: #000000;
vertical-align: middle;
}
..hotbutton

{
cursor: pointer;
background-image: url("../Images/Button2.gif");
background-repeat: no-repeat;
background-position: center center;
color: #ff2020;
font-size: 9px;
text-align: center;
vertical-align: middle;
}

..button2
{
background-image: url("../Images/Button1.gif"); // a bit cute. This is
an image of a button that has been pressed :)
background-repeat: no-repeat;
background-position: center center;
color: green;
cursor:default;
font-size: 9px;
text-align: center;
vertical-align: middle;
}

************************************
These allow me to draw little button images to any shape and style I
want. I use ones with drop shadow created as transparent background
gifs..These move the cursor to pointer type when the mouse moves over..

Here is a typical button drawing HTML fragment:-
*** HTML ***************************

<div class="button1"
style="position: absolute; top: 48px; left: 200px; width: 125px; height:
35px"
id="newproject" onmouseover="this.className='hotbutton'"
onmouseout="this.className='button1'"
onclick="this.className='button2';newproject();" >
<div style="position: absolute; font-weight: bold;
text-align: center; width:95px; left:15px; top:8px">
NEW PROJECT</div>
</div>

****************************************************
The inner div is to place the lettering exactly over the button center
for nice appearance..values depend on the pixel height of the button gif.

Then the onclick function:-
****************************************************
<script>
function newproject()
{
// put your validation code here.
if (valid)
document.forms[0].submit();
else alert ("you fsked up");
}
</script>
****************************************************
So, no actual submit button is ever used. Ok this has a problem on that
it depends utterly on the browser supporting javascript, but frankly, if
they dont. tell them that this page needs it and if they can't be arsed
to upgrade to a browser that does, they can fsck themselves.

once you get to the point where javascript is needed to get the
functionality you want, you have to ask the question of why bother with
most of the ugly form elements in the first place?

You can very easily make your own input elements of type checkbox,
radio, submit and select/option. The only three I haven't yet faked are
text, textarea and file..
 
R

RobG

RobG wrote: [...]
This is the key to the OP's issues.  Firstly, if the button is there
to submit the form, it should be a submit button (i.e. type="submit")..
Click to expand...
Secondly, the validation function should added as a listener to the
form's onsubmit handler, not to the button's onclick handler.
Click to expand...
Finally, the onsubmit handler will return whatever value the function
returns, and the function should return false if it wants to cancel
the submit.
Click to expand...

That's one way.
Click to expand...

It's often recommended here as the best way.

I did this another way.

The submit button isn't a submit button, its a generic button that
calls, on click, a javascript function that does the following
- validates.
Click to expand...

If the button is clicked, what if the user is using IE and submits the
form by pressing enter while the focus is on some other control?

- if validation fails, pops up an alert
Click to expand...

A really annoying way to tell users their input is not what you
expect.

- if validations pases, executes document.forms[0].submit();
Click to expand...

So if the user submits the form by means other than the button,
validation doesn't run. And if javascript is disabled or not
functioning, the user can't submit the form at all.

I don't understand the need to replace native features that are
perfectly functional with problematic scripts. Javascript is
available to enhance the UI, not make it dysfunctional.

[...]
So, no actual submit button is ever used. Ok this has a problem on that
it depends utterly on the browser supporting javascript,
Click to expand...

And the user having scripting turned on, and the script executing
correctly, and the user using the button to submit the form...

but frankly, if
they dont. tell them that this page needs it and if they can't be arsed
to upgrade to a browser that does, they can fsck themselves.
Click to expand...

So you lose say 5% of visitors for the sake of a mass of CSS, images
and script to replace a single HTML element. Not a particularly good
trade-off.

once you get to the point where javascript is needed to get the
functionality you want, you have to ask the question of why bother with
most of the ugly form elements in the first place?

You can very easily make your own input elements of type checkbox,
radio, submit and select/option. The only three I haven't yet faked are
text, textarea and file..
Click to expand...

That is completely the wrong approach. If you are keen to build
brittle, slow and poorly functioning web sites, go for it. But if I
were to stumble across such a site, I wouldn't be there for very long.
 
G

Gregor Kofler

Conrad Lender meinte:
Try it :)
Click to expand...

Ah I see - I should have read the complete script.
npf.elements would be better style, but form nodes do have a length
property and numeric indices.
Click to expand...

Yes, Perhaps not-so-nice style. Alas, DOM2 compliant.

Gregor
 
T

The Natural Philosopher

RobG said:
RobG wrote: [...]
This is the key to the OP's issues. Firstly, if the button is there
to submit the form, it should be a submit button (i.e. type="submit").
Secondly, the validation function should added as a listener to the
form's onsubmit handler, not to the button's onclick handler.
Finally, the onsubmit handler will return whatever value the function
returns, and the function should return false if it wants to cancel
the submit.
Click to expand...
That's one way.
Click to expand...

It's often recommended here as the best way.

I did this another way.

The submit button isn't a submit button, its a generic button that
calls, on click, a javascript function that does the following
- validates.
Click to expand...

If the button is clicked, what if the user is using IE and submits the
form by pressing enter while the focus is on some other control?

- if validation fails, pops up an alert
Click to expand...

A really annoying way to tell users their input is not what you
expect.

- if validations pases, executes document.forms[0].submit();
Click to expand...

So if the user submits the form by means other than the button,
validation doesn't run. And if javascript is disabled or not
functioning, the user can't submit the form at all.

I don't understand the need to replace native features that are
perfectly functional with problematic scripts. Javascript is
available to enhance the UI, not make it dysfunctional.

[...]
So, no actual submit button is ever used. Ok this has a problem on that
it depends utterly on the browser supporting javascript,
Click to expand...

And the user having scripting turned on, and the script executing
correctly, and the user using the button to submit the form...

but frankly, if
they dont. tell them that this page needs it and if they can't be arsed
to upgrade to a browser that does, they can fsck themselves.
Click to expand...

So you lose say 5% of visitors for the sake of a mass of CSS, images
and script to replace a single HTML element. Not a particularly good
trade-off.

once you get to the point where javascript is needed to get the
functionality you want, you have to ask the question of why bother with
most of the ugly form elements in the first place?

You can very easily make your own input elements of type checkbox,
radio, submit and select/option. The only three I haven't yet faked are
text, textarea and file..
Click to expand...

That is completely the wrong approach. If you are keen to build
brittle, slow and poorly functioning web sites, go for it. But if I
were to stumble across such a site, I wouldn't be there for very long.
Click to expand...

Well, that is YOUR religion.

My actual application is custom, and has to match native PC running
software in terms of slick appearance and functionality and speed.

I.e. is in house, and the users will run what is needed to access it.

And has to do what customers are happy to pay for, not what your
religion tell you is correct. *My*( religion would like as not tell
anyone using IE7 to feck off and download a decent browser, or better
still, Linux, but sadly my customers wouldn't take kindly to that.

I don't see why you are taking issues with browsers that don't support
javascript, or having it turned off, on a newsgroup dedicated to writing
javascript.

That's tantamount to saying there is no point in ever using javascript,
as 5% of potential users don't have it/wont use it..

Once you step off the 'HTML ONLY' platform, your are in deep shit anyway
if the user doesn't do javascript.

My take is that you either do

HTML and no javascript.
OR HTML with just a few decorative bits.. which seems hardly worth
dragging out the manual.

OR Assume the user has javascript, and do the best job you can that
supports all the common browsers.

The only point you make that is valid in my view, is disabling the use
of the enter button to submit the form via another route.

The use of alert() was merely an example. Its just as easy to write some
error text into a place on the screen and not use alert() at all.
 
T

Thomas 'PointedEars' Lahn

Conrad said:
Try it :)

npf.elements would be better style,
Click to expand...

It would be the standards-compliant way with regard to indexing. npf.length
and npf would be backwards-compatible to NN 2.0/JS 1.1 (untested yet).
but form nodes do have a length property
Click to expand...

Yes, objects that implement the HTMLFormElement interface have a `length'
property to provide the number of controls in the form.

and numeric indices.
Click to expand...

Not per Specification, that's a proprietary extension from DOM Level 0.
(I really wonder what HTML DOM Specification the two of you have been reading.)

The HTMLFormElement interface does _not_ inherit from the HTMLCollection or
NodeList interfaces, so their item() or namedItem() methods, which would
provide for access through bracket property accessor in ECMAScript
implementations, would not be available in a conforming implementation.

<http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-40002357>

IIRC we have discussed this last week already.


PointedEars
 
R

RobG

RobG said:
RobG wrote: [...]
This is the key to the OP's issues. Firstly, if the button is there
to submit the form, it should be a submit button (i.e. type="submit").
Secondly, the validation function should added as a listener to the
form's onsubmit handler, not to the button's onclick handler.
Finally, the onsubmit handler will return whatever value the function
returns, and the function should return false if it wants to cancel
the submit.
That's one way.
Click to expand...
Click to expand...
It's often recommended here as the best way.
Click to expand...
If the button is clicked, what if the user is using IE and submits the
form by pressing enter while the focus is on some other control?
Click to expand...
A really annoying way to tell users their input is not what you
expect.
- if validations pases, executes document.forms[0].submit();
Click to expand...
Click to expand...
So if the user submits the form by means other than the button,
validation doesn't run. And if javascript is disabled or not
functioning, the user can't submit the form at all.
Click to expand...
I don't understand the need to replace native features that are
perfectly functional with problematic scripts. Javascript is
available to enhance the UI, not make it dysfunctional.
[...]
Click to expand...
So, no actual submit button is ever used. Ok this has a problem on that
it depends utterly on the browser supporting javascript,
Click to expand...
Click to expand...
And the user having scripting turned on, and the script executing
correctly, and the user using the button to submit the form...
Click to expand...
So you lose say 5% of visitors for the sake of a mass of CSS, images
and script to replace a single HTML element. Not a particularly good
trade-off.
Click to expand...
That is completely the wrong approach. If you are keen to build
brittle, slow and poorly functioning web sites, go for it. But if I
were to stumble across such a site, I wouldn't be there for very long.
Click to expand...

Well, that is YOUR religion.
Click to expand...

Religion requires blind faith, what I suggested is the result of
logical thought intended to produce the most robust and reliable
result.

My actual application is custom, and has to match native PC running
software in terms of slick appearance and functionality and speed.
Click to expand...

The assumption here is that suggestions should be for general
application to a web environment. Neither the OP or your suggested
solution indicated a different environment.

I.e. is in house, and the users will run what is needed to access it.
Click to expand...

Even intranet applications should be designed to operate correctly in
more than one browser. It takes very little extra effort, though I am
aware of the commercial pressure when the client specifies a
particular OS and browser version to only develop and test for that
platform.


[...]
I don't see why you are taking issues with browsers that don't support
javascript, or having it turned off, on a newsgroup dedicated to writing
javascript.
Click to expand...

Because javascript should not be used to exclude users from
functionality that would otherwise be available to them. Using a
submit button and listener on the form's submit handler only differs
from your solution in that the validation function is more likely to
actually be called when the form is submitted and the user can submit
the form if javascript fails for any reason.

Surely that is better? I certainly doesn't degrade the user experience
or restrict your options for fake form controls.
That's tantamount to saying there is no point in ever using javascript,
as 5% of potential users don't have it/wont use it..
Click to expand...

Applications designed for general internet use should work with zero
script support, that is the only way graceful degradation can work
effectively. That does not preclude writing applications that are
dependent on scripting, only that where such solutions are suggested,
the limitations should be clearly noted.

Once you step off the 'HTML ONLY' platform, your are in deep shit anyway
if the user doesn't do javascript.

My take is that you either do

HTML and no javascript.
OR HTML with just a few decorative bits.. which seems hardly worth
dragging out the manual.
Click to expand...

Pages should be designed to work without script or CSS, features can
then be added to enhance the user experience. It forces a rigour to
the initial design and layout that has great benefits later - pages
tend to be cleaner, simpler and easier to work with than those that
are designed to work with bucketloads of script and CSS or die.

One of my pet hates is the use of complex CSS selectors to add
"unobtrusive" javascript - as soon as the page layout changes
marginally, stuff just stops working for no particular reason, or goes
haywire.

OR Assume the user has javascript, and do the best job you can that
supports all the common browsers.
Click to expand...

The list of "all the common browsers" changes frequently - 18 months
ago, who was designing for IE8, Chrome, Safari 3 or Firefox 3? Far
better to write stable, robust applications that assume minimal
support for script but provide an enhanced UI in reasonably modern,
standards-compliant browsers.

The only point you make that is valid in my view, is disabling the use
of the enter button to submit the form via another route.
Click to expand...

I did not suggest that at all, it's illogical to break standard
functionality to accommodate a poor design decision that is easily
fixed in a more robust way. All you need to do is move the listener
from the button to the form - zero extra script and the user's browser
still works how they expect it to.
 
A

Andrew Falanga

No problem. I've put some recommendations in parentheses.




(It's considered good style in JS to start the names of functions with a
lower-case letter unless the function is intended as a constructor)
Click to expand...

Interesting and thanks. This will take some getting used to because
I've developed the habit of beginning variables with lowercase
characters and my functions in uppercase.
(This will evaluate npf.length on every iteration. Since the length is
constant, this could be written more efficiently as:
  for (var i = 0, len = npf.length; i < len; i++)
)
Click to expand...

This is a very good suggestion and, obviously, I didn't think about it
(which is rather odd because I usually do when programming in other
languages C++ notably).
      if(npf.elements.nodeType == "textarea")
         continue;
Click to expand...

      if(npf.elements.value == "") {
Click to expand...


(Is a single space considered valid input?)
Click to expand...


At this time it shouldn't be, but thanks for the pointer.
(That's not really a submit button (type="submit")).
Click to expand...

I know. The page code originally was <input type=submit ...> but
because the javascript tutorial I'm going off of on line, www.w3schools.com,
use the type=button, I changed it.
You can avoid the default action of the button like this:

  <input type="submit" onclick="return CheckFormValues()" ...>

In the validation function, return true/false. You may also want to pass
the form element directly; this will save you the getElementById() call:
Click to expand...

Can you explain how this works, from a "mechanics standpoint?" How
exactly does the "onclick" attribute work to recognize the difference
between a true/false return?
  function CheckFormValues(npr) { ...
  ..
  <input ... onclick="return CheckFormValues(this.form)" ...>
Click to expand...

This is absolutely fantastic. I didn't realize this could be done.
What does the function definition look like? Is it simply:
function checkFormValues(var) {
// stuff
}

And then I use the particular object methods in the function?


Thanks,
Andy
 
A

Andrew Falanga

On 2008-11-17 01:49, Andrew Falanga wrote:
Click to expand...
No problem. I've put some recommendations in parentheses.
Click to expand...
(It's considered good style in JS to start the names of functions with a
lower-case letter unless the function is intended as a constructor)
Click to expand...
(This will evaluate npf.length on every iteration. Since the length is
constant, this could be written more efficiently as:
  for (var i = 0, len = npf.length; i < len; i++)
)
      if(npf.elements.nodeType == "textarea")
         continue;
      if(npf.elements.value == "") {
Click to expand...
Click to expand...

(Is a single space considered valid input?)
Click to expand...

This is the key to the OP's issues.  Firstly, if the button is there
to submit the form, it should be a submit button (i.e. type="submit").

Secondly, the validation function should added as a listener to the
form's onsubmit handler, not to the button's onclick handler.
Click to expand...


I completely agree with this one. This makes the most sense and is
clear in the code for what I intend.

Thanks,
Andy
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Issue with passing fetched data to POST form. How can I? 0
Registration Form 7
Mandatory Elements To Conduct JavaScript Form Manipulation 7
C# MVC Razor page form 0
action_page.php form 2
Need Help With a Signup Form 10
How can I guarantee that the all callback functions of the first Ajax API call have finished executing before initiating the 2 call in JavaScript? 2
How to submit form after calling curl post 4

Members online

No members online now.
Total: 18 (members: 0, guests: 18)
Robots: 231

Forum statistics

Threads
473,755
Messages
2,569,537
Members
45,023
Latest member
websitedesig25

Latest Threads

Top