Form name not working

Why won't this work?
I am passing the name of the form (I have two that use this validation
script) but I keep getting an error.
Error reads: "document.which_form.name is null or not an object"

HTML-----------
Form is ----> <form action="thanks.php" method="post" name="contact_form"
id="contact_form">
Name -------> <input type="text" name="name" id="name" size="25">
Button sends code -----> <input type="button" value="Submit Form"
onClick="contact_validate('contact_form')">

JAVASCRIPT-----------
function contact_validate(which_form) {
var field_errors = "The following field(s) are required: \n\n";
var errors = 0;
// If name is null
if (document.which_form["name"].value == '') {
//alert("Please enter your name");
//return;
field_errors = field_errors+"Name - Please enter your name \n";
errors++;
}

Thanks,
CWJ

CJ wrote:[color=blue]
> Why won't this work?
> I am passing the name of the form (I have two that use this validation
> script) but I keep getting an error.
> Error reads: "document.which_form.name is null or not an object"
>
> HTML-----------
> Form is ----> <form action="thanks.php" method="post"
> name="contact_form" id="contact_form">
> Name -------> <input type="text" name="name" id="name" size="25">
> Button sends code -----> <input type="button" value="Submit Form"
> onClick="contact_validate('contact_form')">
>
> JAVASCRIPT-----------
> function contact_validate(which_form) {
> var field_errors = "The following field(s) are required: \n\n";
> var errors = 0;
> // If name is null
> if (document.which_form["name"].value == '') {
> //alert("Please enter your name");
> //return;
> field_errors = field_errors+"Name - Please enter your name \n";
> errors++;
> }
>
> Thanks,
> CWJ[/color]

1) Move the form validation to the <form>'s onsubmit handler - you don't need to
pass a reference to the form:

<form action="thanks.php" method="post" onsubmit="return contact_validate()">
<input type="text" name="name" id="name" size="25"/>
<input type="submit" value="Submit Form">
</form>

2) Update your validation function

- reference the 'name' field using document.getElementById()
- return false if there are errors - so the form *doesn't* submit
- return true if there are no errors - so the form *does* submit

function contact_validate() {
var field_errors = "The following field(s) are required: \n\n";
var errors = 0;
// If name is null
if ( document.getElementById( 'name' ).value == '') {
field_errors = field_errors+"Name - Please enter your name \n";
errors++;
}
if ( errors > 0 ) {
alert( field_errors);
return false;
}
return true
}

Thanks, that did the trick.

I appreciate the help.

CWJ

"DB McGee" <noreply@noreply.com> wrote in message
news:fLFLb.52090$AAe1.7606@news01.bloor.is.net.cab le.rogers.com...
CJ wrote:[color=blue]
> Why won't this work?
> I am passing the name of the form (I have two that use this validation
> script) but I keep getting an error.
> Error reads: "document.which_form.name is null or not an object"
>
> HTML-----------
> Form is ----> <form action="thanks.php" method="post"
> name="contact_form" id="contact_form">
> Name -------> <input type="text" name="name" id="name" size="25">
> Button sends code -----> <input type="button" value="Submit Form"
> onClick="contact_validate('contact_form')">
>
> JAVASCRIPT-----------
> function contact_validate(which_form) {
> var field_errors = "The following field(s) are required: \n\n";
> var errors = 0;
> // If name is null
> if (document.which_form["name"].value == '') {
> //alert("Please enter your name");
> //return;
> field_errors = field_errors+"Name - Please enter your name \n";
> errors++;
> }
>
> Thanks,
> CWJ[/color]

1) Move the form validation to the <form>'s onsubmit handler - you don't
need to
pass a reference to the form:

<form action="thanks.php" method="post" onsubmit="return
contact_validate()">
<input type="text" name="name" id="name" size="25"/>
<input type="submit" value="Submit Form">
</form>

2) Update your validation function

- reference the 'name' field using document.getElementById()
- return false if there are errors - so the form *doesn't* submit
- return true if there are no errors - so the form *does* submit

function contact_validate() {
var field_errors = "The following field(s) are required: \n\n";
var errors = 0;
// If name is null
if ( document.getElementById( 'name' ).value == '') {
field_errors = field_errors+"Name - Please enter your name \n";
errors++;
}
if ( errors > 0 ) {
alert( field_errors);
return false;
}
return true
}

"DB McGee" <noreply@noreply.com> wrote in message
news:fLFLb.52090$AAe1.7606@news01.bloor.is.net.cab le.rogers.com...
<snip>[color=blue]
>1) Move the form validation to the <form>'s onsubmit handler -
>you don't need to pass a reference to the form:
>
><form action="thanks.php" method="post"
> onsubmit="return contact_validate()">[/color]

On the contrary, calling the validation function from the onsubmit
handler is an ideal opportunity to anonymously pass a generalised
validation function a reference to the FORM element that it is to be
applied to. In the internally generated event handling function that is
created using the onsubmit attribute string the - this - keyword is
always a reference to the FORM element to which the function is assigned
as a method:-

onsubmit="return contact_validate(this);"

- Removes the need to be interested in the name of the form.
[color=blue]
><input type="text" name="name" id="name" size="25"/>[/color]
<snip>

"name" could be a bad name for a form element and also for the ID of an
element as the W3C HTML DOM specification requires that named and/or
IDed properties are made available as named properties of the FORM
element, so the above INPUT element would be available as a property of
the form under the name "name". However, the FORM element is also
required to have a property with the name "name" that represents the
name of the form.

Implementations may choose to replace the name property of the form with
a reference to the INPUT element with the name "name" or they might not,
the grounds for that decision are not specified. Generally it is unwise
to give form elements names (or IDs) that correspond with existing
properties of a FORM element, especially if those properties are going
to be used. As property names are case sensitive it is only necessary,
for exempt, to capitalise the name/ID to avoid the risk of conflicts.
[color=blue]
>2) Update your validation function
>
>- reference the 'name' field using document.getElementById()[/color]
<snip>

If the point of the function is to provide a general function for use
with multiple forms, and the ID of the element is to be hard coded in
the function then the strategy will not work as the getElementById
method is required to return the first element on the page with the
corresponding ID, so it will always return a reference to the INPUT
element IDed as "name" in the first form on the page. But HTML requires
that an ID be unique on the page so hard coding an ID string into a
function is not viable if the function is intended to act with more than
one element.

The result is that if the string used to look up the reference to an
INPUT element is to be hard coded into a general validation function
then an ID cannot be used, and so getElementById is an inappropriate
method of acquiring the required reference.

Given a need to resolve a reference to a named INPUT element within a
form, where the same method and name string must be used with several
forms, the best place to look-up the reference to the input element is
as a named property of the - elements - collection of the form. An
approach that conforms with the W3C HTML DOM specification and is also
back-compatible with every JavaScript capable browser that also
understands what a form is:-

function contact_validate(formRef) {
var field_errors = "The following field(s) are required: \n\n";
var errors = 0;
if ( formRef.elements[ 'name' ].value == '') {
field_errors = field_errors+"Name - Please enter your name \n";
errors++;
}
if ( errors > 0 ) {
alert( field_errors);
return false;
}
return true
}

Richard.

In article <fLFLb.52090$AAe1.7606@news01.bloor.is.net.cable.r ogers.com>, "DB
McGee" <noreply@noreply.com> writes:
[color=blue]
>CJ wrote:[color=green]
>> Why won't this work?
>> I am passing the name of the form (I have two that use this validation
>> script) but I keep getting an error.
>> Error reads: "document.which_form.name is null or not an object"[/color][/color]

thats because which_form is a variable, see below for a solution.
[color=blue][color=green]
>> HTML-----------
>> Form is ----> <form action="thanks.php" method="post"
>> name="contact_form" id="contact_form">
>> Name -------> <input type="text" name="name" id="name" size="25">
>> Button sends code -----> <input type="button" value="Submit Form"
>> onClick="contact_validate('contact_form')">
>>
>> JAVASCRIPT-----------
>> function contact_validate(which_form) {
>> var field_errors = "The following field(s) are required: \n\n";
>> var errors = 0;
>> // If name is null
>> if (document.which_form["name"].value == '') {[/color][/color]

document.forms[which_form].elements['name'].value
[color=blue][color=green]
>> //alert("Please enter your name");
>> //return;
>> field_errors = field_errors+"Name - Please enter your name \n";
>> errors++;
>> }
>>
>> Thanks,
>> CWJ[/color]
>
>
>1) Move the form validation to the <form>'s onsubmit handler - you don't need
>to pass a reference to the form:
>
><form action="thanks.php" method="post" onsubmit="return contact_validate()">
> <input type="text" name="name" id="name" size="25"/>
> <input type="submit" value="Submit Form">
></form>
>
>2) Update your validation function
>
>- reference the 'name' field using document.getElementById()[/color]

And break it in browsers that don't support it? When the document.forms
collection can handle it in any browser that supports forms?
[color=blue]
>- return false if there are errors - so the form *doesn't* submit
>- return true if there are no errors - so the form *does* submit
>
>function contact_validate() {
> var field_errors = "The following field(s) are required: \n\n";
> var errors = 0;
> // If name is null
> if ( document.getElementById( 'name' ).value == '') {[/color]

The OP stated that he had two forms that use the same function, so it should be
reasonably safe to assume that each form has a field with name="name" (not sure
I would name it name, perhaps fName or such), then the browser will never get
one of them. Utterly breaks the script.
[color=blue]
> field_errors = field_errors+"Name - Please enter your name \n";
> errors++;
> }
> if ( errors > 0 ) {
> alert( field_errors);
> return false;
> }
> return true
>}
>[/color]

--
Randy

"Richard Cornford" <Richard@litotes.demon.co.uk> writes:

....[color=blue]
> as the W3C HTML DOM specification requires that named and/or
> IDed properties are made available as named properties of the FORM
> element,[/color]

Do you have a reference for that? I don't see anything about that in
the ECMAScript bindings for W3C HTML DOM (1 or 2, they agree) under
HTMLFormElement. It has the "elements" collection, but that is it.

All existing browsers do it this way, but it's not in the W3C DOM as
far as I can see (and shouldn't be, as it's polluting the namespace
and giving exactly the problems you point out).

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

"Lasse Reichstein Nielsen" <lrn@hotpop.com> wrote in message
news:4qv4a5yy.fsf@hotpop.com...[color=blue]
> "Richard Cornford" <Richard@litotes.demon.co.uk> writes:
>
> ...[color=green]
>>as the W3C HTML DOM specification requires that named and/or
>>IDed properties are made available as named properties of the
>>FORM element,[/color]
>
>Do you have a reference for that? I don't see anything about
>that in the ECMAScript bindings for W3C HTML DOM (1 or 2, they
>agree) under HTMLFormElement. It has the "elements" collection,
>but that is it.[/color]

<quote>
Interface HTMLFormElement
The FORM element encompasses behavior similar to a collection
and an element. It provides direct access to the contained form
controls as well as the attributes of the form element.
...
length of type long, readonly
The number of form controls in the form.
</quote>

That is my interpretation of "behavior similar to a collection" and
"direct access to the contained form controls". On the grounds that if
it is a collection it has to be a collection of something and the form
elements ore the obvious candidate, and I would describe making the
elements available through the - elements - collection as indirect.
[color=blue]
>All existing browsers do it this way, but it's not in the W3C
>DOM as far as I can see (and shouldn't be, as it's polluting
>the namespace and giving exactly the problems you point out).[/color]

A lot of the HTML DOM is a formalisation of existing browser behaviour,
but it probably was a mistake for the W3C to do this (assuming you
cannot find a reasonable alternative interpretation0.

Richard.

"Richard Cornford" <Richard@litotes.demon.co.uk> writes:
[color=blue]
> <quote>
> Interface HTMLFormElement
> The FORM element encompasses behavior similar to a collection
> and an element. It provides direct access to the contained form
> controls as well as the attributes of the form element.
> ...
> length of type long, readonly
> The number of form controls in the form.
> </quote>[/color]

I can see why this can be taken to mean that the HTML element is a
collection itself. However, the IDL in DOM 2 HTML can be used in
strictly typed OO languages, like Java or C++, to create objects
implementing the HTMLFormElement interface. They have no provision
for adding arbitrarily named propertie to such objects.

With that in mind, I read the "compasses behavior similar to a
collection" as merely saying what should be possible through the
FormElement, not how it is implemented. The implementation makes
the collection behavior available through the "elements" collection.

Compare it to the HTMLSelectElement. It says:
---
The contained options can be directly accessed through the select
element as a collection.
---
Again, I could read it as saying that a select element should act
as a collection, but all the interface requires is that it *contains*
the options collection. Select elements also have a length property
which duplicates the one in the options collection.

So, reading the DOM 2 IDL as a specification for Java, there is no way
forms or selects can be collections - they don't have the appropriate
methods (item, namedItem). There is nothing in the ECMAScript binding
that makes it special (as there is for collections, allowing access
through the [...] property accessor).
[color=blue]
> That is my interpretation of "behavior similar to a collection" and
> "direct access to the contained form controls". On the grounds that if
> it is a collection it has to be a collection of something and the form
> elements ore the obvious candidate, and I would describe making the
> elements available through the - elements - collection as indirect.[/color]

The elements property is read-only and is bound to this particular
form. Thinking in OO modelling terminology, that makes it a component
of the form element, not just reference by it. Having a collection
component would count as direct enough for me.
[color=blue]
> A lot of the HTML DOM is a formalisation of existing browser behaviour,
> but it probably was a mistake for the W3C to do this (assuming you
> cannot find a reasonable alternative interpretation0.[/color]

I try :) But only because your interpretation makes no sense in, e.g.,
Java with the defined interface, and there is no sign that the
ECMAScript binding is doing anything special.

/L
--
Lasse Reichstein Nielsen - lrn@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

On Sat, 10 Jan 2004 12:05:24 +0100, Lasse Reichstein Nielsen
<lrn@hotpop.com> wrote:
[color=blue]
>"Richard Cornford" <Richard@litotes.demon.co.uk> writes:[color=green]
>> A lot of the HTML DOM is a formalisation of existing browser behaviour,
>> but it probably was a mistake for the W3C to do this (assuming you
>> cannot find a reasonable alternative interpretation0.[/color]
>
>I try :) But only because your interpretation makes no sense in, e.g.,
>Java with the defined interface, and there is no sign that the
>ECMAScript binding is doing anything special.[/color]

I'm inclined with Richard here, but the DOM WG are very good at
responding to questions and clarify their testcases and more if you
ask such questions on the list (they recently clarified what
setAttributeNS('urn://foo','chicken','test') does for me) I'd
encourage everyone to ask them if they're unsure, it's just an email
to www-dom@w3.org after all.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

"Lasse Reichstein Nielsen" <lrn@hotpop.com> wrote in message
news:eku8ukqz.fsf@hotpop.com...
<snip>[color=blue]
> Compare it to the HTMLSelectElement. It says:
> ---
> The contained options can be directly accessed through the select
> element as a collection.
> ---
>Again, I could read it as saying that a select element should act
>as a collection, but all the interface requires is that it *contains*
>the options collection. Select elements also have a length property
>which duplicates the one in the options collection.[/color]

It could be read that way, and I think that it might have been, as
SELECT elements on some modern browsers do make the options available as
indexed (and possibly named) properties. So:-

sel.options[sel.selectedInded]

-refers to the same option object as:-

sel[sel.selectedIndes]

And just to muddy the waters a bit more they also implement - item -
and - namedItem -.
[color=blue]
>So, reading the DOM 2 IDL as a specification for Java, there is
>no way forms or selects can be collections - they don't have the
>appropriate methods (item, namedItem). ...[/color]
<snip>

The Java argument is good, though it is clear from the HTMLElement
interface that all of the other elements are expected to also implement
that interface. So a Java object could implement HTMLCollection in
addition to HTMLElement and HTMLFormElement. It doesn't work like that
for the browser form objects as they don't implement - item - or -
namedItem - in practice, and if an HTMLFormElement implementing object
is intended to implement HTMLCollection there seems no point in
including - length - in HTMLFormElement .

Oh well, it probably will be easier to do as Jim suggests and ask them
what they intended (might encourage them to be a bit less ambiguous in
the next version) but I have the FAQ to worry about at the moment so not
for a week or two.

On the whole I still don't see having an elements collection as
sufficient to justify the "behavior similar to a collection" statement.

Richard.

Richard Cornford wrote:
[color=blue]
> SELECT elements on some modern browsers do make the options
> available as indexed (and possibly named) properties. So:-
>
> sel.options[sel.selectedInded]
>
> -refers to the same option object as:-
>
> sel[sel.selectedIndes]
>
> And just to muddy the waters a bit more they also implement
> - item - and - namedItem -.[/color]

If I understand you correctly, you are mistaken here. UAs that
implement the W3C-DOM Level 2 "HTMLOptionsCollection" interface
also implement its "item" and "namedItem" methods. The []
property accessor is just a shortcut for these methods for
ECMAScript implementations, depending on the type of its index,
which is described in the ECMAScript Language Binding section of
the W3C-DOM Level 2 HTML Specification.

What you describe as possible shortcut is merely a proprietary
feature. The latter would then be a proprietary shortcut for
the former, not vice-versa. Note that there is a Select object
in the core JavaScript language up to v1.3, before the W3C-DOM.
It is likely that some vendors merged DOMs for their UAs to be
backwards compatible.

PointedEars

"Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message
news:402C05EC.3060406@PointedEars.de...
<snip>[color=blue]
>If I understand you correctly, you are mistaken here. UAs that
>implement the W3C-DOM Level 2 "HTMLOptionsCollection" interface
>also implement its "item" and "namedItem" methods.[/color]

The object that the W3C HTML DOM specification unambiguously requires to
implement the HTMLOptionsCollection interface is the object referenced
by the - options - property of the HTMLSelectElement interface not the
HTMLSelectElement interface implementing object itself. Where the spec
is ambiguous is in possibly implying that the HTMLSelectElement
interface should also implement the HTMLOptionsCollection. But that is
only one possible interpretation of some very vague wording.

Lasse had pointed out that the fact that the HTMLFormElement interface
implementing objects did not in reality poses the - item - and -
namedItem - methods strengthened his argument that HTMLFormElement
itself was not also intended (by the spec) to serve the role of a
collection of controls.

And I was pointing out that the objects implementing the
HTMLSelectElement interface do in fact implement the properties and
method of the HTMLOptionsCollection. So in so far as the absence of -
item - and - namedItem - can be used to resolve the ambiguous wording
concerning HTMLFormElement in a way that suggest that it not also be a
collection of controls, their presence on the HTMLSelectElement
interface implementing object would force an opposite interpretation on
the even more ambiguous wording concerning that interface.

In both cases the actual behaviour correspond with pre-existing (and so
proprietary) and (apparently) universally implemented behaviour, The
question was; is the W3C DOM specification attempting to formalise that
behaviour or is it only trying to formalise the contained - elements -
and - options - collections (respectively)? And that question is
unresolved.
[color=blue]
>The []
>property accessor is just a shortcut for these methods for
>ECMAScript implementations, depending on the type of its index,
>which is described in the ECMAScript Language Binding section of
>the W3C-DOM Level 2 HTML Specification.
>
>What you describe as possible shortcut is merely a proprietary
>feature.[/color]

A large part of the HTML DOM specification (and particularly surrounding
forms) is a formalisation of proprietary features that had become so
widely adopted that they were virtually standard already.
[color=blue]
>The latter would then be a proprietary shortcut for
>the former, not vice-versa.[/color]

I didn't say that either was a shortcut for the other, I said that they
referred to the same object.
[color=blue]
>Note that there is a Select object
>in the core JavaScript language up to v1.3, ...[/color]
<snip>

You did not read a single reference to a Select object anywhere in my
preceding post.

Richard.

Richard Cornford wrote:
[color=blue]
> "Thomas 'PointedEars' Lahn" <PointedEars@web.de> wrote in message
> news:402C05EC.3060406@PointedEars.de...[color=green]
>>The latter would then be a proprietary shortcut for
>>the former, not vice-versa.[/color]
>
> I didn't say that either was a shortcut for the other, I said that
> they referred to the same object.[/color]

Which means the same thing, using other words.
[color=blue][color=green]
>>Note that there is a Select object
>>in the core JavaScript language up to v1.3, ...[/color]
> <snip>
>
> You did not read a single reference to a Select object anywhere in my
> preceding post.[/color]

The point is that what looks like an HTMLSelectElement object in the
resulting DOM could be the result of merging the previous language-based
"DOM" with the current implementation-based DOM just to stay
backwards-compatible.

PointedEars