469,923 Members | 1,548 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,923 developers. It's quick & easy.

Setting the a form's hidden input type

Hi,

I am trying to change and pass the value of a hidden input type on a
form tag to a cgi processing script based on the value of a checkbox
within the form:

function CheckBoxes () {
if (document.MyForm.CheckBox1.checked) {
document.MyForm.recipient.value = "2";
document.MyForm.submit();
}
}
...

<form name="MyForm" action="http://www.mycompany.com/cgi/MailMyForm.pl"
method="post" onSubmit="return CheckBoxes()">
<input type="hidden" name="recipient" value="1">
<input name="CheckBox1" type="checkbox" value="yes">
...
</form>

Obviously, this is a simplified version of the real example.

The "recipient" value of "1" is a default recipient's e-mail address in
case no checkboxes are selected. If (in this case) the checkbox
"CheckBox1" is checked, then "recipient" should get set to a value of
"2" which the cgi script will recognize as a different e-mail address
and process the form accordingly (it would just go to the e-mail
address defined in the cgi script for a "recipient" value of "2").

Any idea why this won't work? Is it that I cannot change the value of
"recipient"?

Any help is appreciated.

Jul 23 '05 #1
12 1956
Jim Tome wrote:
function CheckBoxes () {
if (document.MyForm.CheckBox1.checked) {
document.MyForm.recipient.value = "2";
document.MyForm.submit();
}
}
..

<form name="MyForm" action="http://www.mycompany.com/cgi/MailMyForm.pl"
method="post" onSubmit="return CheckBoxes()">

<input name="CheckBox1" type="checkbox" value="yes">
..
</form>


Why not get rid of the function, and use the onclick event handler of
the checkbox in its stead?

<form action="http://www.mycompany.com/cgi/MailMyForm.pl"
method="post" >
<input type="hidden" name="recipient" value="1">
<input name="CheckBox1" type="checkbox" value="yes"
onclick='recipient.value=this.checked?"2":"1"'>

However you need to be certain that the user has javascript enabled.
Mick
Jul 23 '05 #2
On Thu, 06 May 2004 15:19:23 GMT, Mick White
<mw******@BOGUSrochester.rr.com> wrote:

[snip]
<input name="CheckBox1" type="checkbox" value="yes"
onclick='recipient.value=this.checked?"2":"1"'>


That won't work in most browsers. Remember that using ids and names as
global identifiers is a Microsoft-ism that isn't standardised, and
certainly not copied in all cases.

onclick="this.form.elements['recipient'].value=this.checked?'2':'1'"

Probably best in a function.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 23 '05 #3
Yes, thank for your suggestion. My next question is, suppose there are
three checkboxes (any or all of which can be selected). Checking a
checkbox indicates that a copy of the form's submission get e-mailed to
a separate recipient depending on the checkbox checked (so, in this
simple example, the form would e-mail to one, two or three people).

How can I test and handle this?

Thanks again for your help ? sometime I get too close to these things
to see the simple solution!

On 2004-05-06 10:19:23 -0500, Mick White <mw******@BOGUSrochester.rr.com> said:
Jim Tome wrote:
function CheckBoxes () {
if (document.MyForm.CheckBox1.checked) {
document.MyForm.recipient.value = "2";
document.MyForm.submit();
}
}
..

<form name="MyForm" action="http://www.mycompany.com/cgi/MailMyForm.pl"
method="post" onSubmit="return CheckBoxes()">

<input name="CheckBox1" type="checkbox" value="yes">
..
</form>


Why not get rid of the function, and use the onclick event handler of
the checkbox in its stead?

<form action="http://www.mycompany.com/cgi/MailMyForm.pl"
method="post" >
<input type="hidden" name="recipient" value="1">
<input name="CheckBox1" type="checkbox" value="yes"
onclick='recipient.value=this.checked?"2":"1"'>

However you need to be certain that the user has javascript enabled.
Mick

Jul 23 '05 #4
Michael Winter wrote:
On Thu, 06 May 2004 15:19:23 GMT, Mick White
<mw******@BOGUSrochester.rr.com> wrote:

[snip]
<input name="CheckBox1" type="checkbox" value="yes"
onclick='recipient.value=this.checked?"2":"1"'>

That won't work in most browsers. Remember that using ids and names as
global identifiers is a Microsoft-ism that isn't standardised, and
certainly not copied in all cases.

onclick="this.form.elements['recipient'].value=this.checked?'2':'1'"

Probably best in a function.

Mike

Yes, proper, unambiguous, references are important. I should note that.

I am not sure which browsers would fail. None of my current crop, each
is tolerant of my miscoding!!.

For a one-off, I wouldn't create a function. Your points are well taken,
though.
Mick
Jul 23 '05 #5
On Thu, 06 May 2004 16:07:47 GMT, Mick White
<mw******@BOGUSrochester.rr.com> wrote:
Michael Winter wrote:
On Thu, 06 May 2004 15:19:23 GMT, Mick White
<mw******@BOGUSrochester.rr.com> wrote:

[snip]
<input name="CheckBox1" type="checkbox" value="yes"
onclick='recipient.value=this.checked?"2":"1"'>

[snip]
I am not sure which browsers would fail. None of my current crop, each
is tolerant of my miscoding!!.


All Mozilla-based browsers will fail with unqualified references like the
above.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 23 '05 #6

On Thu, 06 May 2004 16:07:47 GMT, Mick White
<mw******@BOGUSrochester.rr.com> wrote:
[snip]

<input name="CheckBox1" type="checkbox" value="yes"
onclick='recipient.value=this.checked?"2":"1"'>

[snip]

Michael Winter wrote: All Mozilla-based browsers will fail with unqualified references like
the above.

Mike

http://www.mickweb.com/demo/formRef.html

Not to belabour the point, but it works in Netscape 7, IE 5.2, Safari
1.1 and Firefox 1.8 (All Mac)
I'm not which of these browsers are Mozilla based or not.
Mick
Jul 23 '05 #7
Michael Winter wrote:
On Thu, 06 May 2004 16:07:47 GMT, Mick White
<mw******@BOGUSrochester.rr.com> wrote:
Michael Winter wrote:
On Thu, 06 May 2004 15:19:23 GMT, Mick White
<mw******@BOGUSrochester.rr.com> wrote:

[snip]

<input name="CheckBox1" type="checkbox" value="yes"
onclick='recipient.value=this.checked?"2":"1"'>


[snip]
I am not sure which browsers would fail. None of my current crop, each
is tolerant of my miscoding!!.


All Mozilla-based browsers will fail with unqualified references like the
above.

Mike


For some reason the code in a form element event handler executes in the
context (or namespace or whatever you want to call it) of the container form,
as a result:

<form>
<input type="text" name="recipient">
<input name="CheckBox1" type="checkbox"
value="yes" onclick="recipient.value=this.checked?2:1">
</form>

works just fine in Firefox 0.8, Netscape 4.78 and Opera 7.23. I recall a
discussion about this some time ago (don't have time to google for it right
now) and it seems to me that this is in fact documented behaviour and can be
relied on. Of course there are a large number of reasons to fully qualify the
reference, just pointing out that it isn't actually necessary in this case.

--
| Grant Wagner <gw*****@agricoreunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html

* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp

* Netscape 6/7 DOM Reference available at:
* http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
* http://www.mozilla.org/docs/web-deve...upgrade_2.html
Jul 23 '05 #8
On Thu, 06 May 2004 19:34:29 GMT, Grant Wagner
<gw*****@agricoreunited.com> wrote:

[snip]
For some reason the code in a form element event handler executes in the
context (or namespace or whatever you want to call it) of the container
form, as a result:

<form>
<input type="text" name="recipient">
<input name="CheckBox1" type="checkbox"
value="yes" onclick="recipient.value=this.checked?2:1">
</form>

works just fine in Firefox 0.8, Netscape 4.78 and Opera 7.23. I recall a
discussion about this some time ago (don't have time to google for it
right now) and it seems to me that this is in fact documented behaviour
and can be relied on. Of course there are a large number of reasons to
fully qualify the reference, just pointing out that it isn't actually
necessary in this case.


I can't find any documentation to support this, nor can I think of any
reason why it should be so. In fact, both Netscape and Microsoft state
that you should either use the name of the element or the elements
collection in conjunction with the form name or the forms collection (they
don't mention named look-ups with the collections):

myForm.myInput
myForm.elements[0]

Of course, only the latter, in conjunction with the forms collection not
the form name, is standardised.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 23 '05 #9
On Thu, 06 May 2004 18:56:01 GMT, Mick White
<mw******@BOGUSrochester.rr.com> wrote:

[unqualified reference from inside a form]
Not to belabour the point, but it works in Netscape 7, IE 5.2, Safari
1.1 and Firefox 1.8 (All Mac)
True, but why not use the method that is more likely to work? Moreover, a
fully qualified reference documents itself.

I tested the success of unqualified controls accesses from outside of the
form. The tests involve whether the control is inside a form (F) and if a
name (N) or id (I) is used. The success (S) is qualified by browser.

F I N S
n y n IE, Opera
n n y IE, Opera
y y n -none-
y n y -none-

Mozilla 1.8a and NN4 failed all four. Strangly, Microsoft's documentation
state that the third (an id'd control inside a form) should work, yet it
doesn't. From inside a form:

I N S
y n IE, Opera, Mozilla
n y IE, Opera, Mozilla, NN4

Using a fully qualified reference works in all cases, except in NN4 when
the control or form uses an id exclusively.
I'm not which of these browsers are Mozilla based or not.


Only Netscape, as far as I'm aware, though Firefox (don't you mean 0.8?)
is Mozilla Firefox.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 23 '05 #10
Michael Winter wrote:
On Thu, 06 May 2004 18:56:01 GMT, Mick White
<mw******@BOGUSrochester.rr.com> wrote:

[unqualified reference from inside a form]
Not to belabour the point, but it works in Netscape 7, IE 5.2, Safari
1.1 and Firefox 1.8 (All Mac)

True, but why not use the method that is more likely to work? Moreover,
a fully qualified reference documents itself.

I tested the success of unqualified controls accesses from outside of
the form. The tests involve whether the control is inside a form (F) and
if a name (N) or id (I) is used. The success (S) is qualified by browser.

F I N S
n y n IE, Opera
n n y IE, Opera
y y n -none-
y n y -none-

Mozilla 1.8a and NN4 failed all four. Strangly, Microsoft's
documentation state that the third (an id'd control inside a form)
should work, yet it doesn't. From inside a form:

I N S
y n IE, Opera, Mozilla
n y IE, Opera, Mozilla, NN4

Using a fully qualified reference works in all cases, except in NN4 when
the control or form uses an id exclusively.
I'm not which of these browsers are Mozilla based or not.

Only Netscape, as far as I'm aware, though Firefox (don't you mean 0.8?)
is Mozilla Firefox.

Mike


Thanks, Mike, I always surround form controls with form tags, and use
the name attribute, I am still looking out for the obscenely aging NN4
browser.
Is the dot syntax deprecated or is this a MS thing ?
document.formName.elementName.elementProperty

Mick

Jul 23 '05 #11
On Thu, 06 May 2004 23:00:34 GMT, Mick White
<mw******@BOGUSrochester.rr.com> wrote:

[snip]
Is the dot syntax deprecated or is this a MS thing ?
document.formName.elementName.elementProperty


It's not specified in the DOM, but both Microsoft and Netscape specify
that method in their JavaScript documentation. As most, if not all,
browsers follow one of these precedents, it's almost guaranteed to work.
If you want to be really safe, you could just stick to the collections.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)
Jul 23 '05 #12
Mick White wrote:
Michael Winter wrote:
Mick White wrote:
> <input name="CheckBox1" type="checkbox" value="yes"
> onclick='recipient.value=this.checked?"2":"1"'>
<snip> All Mozilla-based browsers will fail with unqualified references
like the above.
<snip> Not to belabour the point, but it works in Netscape 7, IE 5.2, Safari
1.1 and Firefox 1.8 (All Mac)
I'm not which of these browsers are Mozilla based or not.


When browsers produce a function from the code provided as the string
value for an event handling attribute some of them provide that function
with a custom scope chain. They vary in how they do this, and which
objects end up on that custom scope chain (if any). But most that
provide a custom scope chain will include any containing form element on
the scope chain used, so the unqualified reference - recipient - will be
resolved as the property of the form element with that name.

However, while this behaviour is common it is not universal and there
are browsers that would be 100% functional with Michael's fully
qualified property accessor that will fail with the unqualified version.
Two examples are Opera <= 6[1] and NetFront.

There was a more detailed examination of this subject last year:-

<URl;
http://groups.google.com/groups?selm...300dec7%40news.
demon.co.uk >

For cross-browser scripting I would recommend writing event handling
attribute code as if it was not going to have a custom scope chain
available to it. Property accessors that would be functional when used
in a javascript function assigned, as an event handler will always be
reliable when used in HTML attribute strings.

Richard.

[1] When Opera <= 6 is spoofing IE it makes named and IDed elements
available as named properties of the global object, so the unqualified
identifier would be resolved as the corresponding form control, but not
on other spoofing modes.
Jul 23 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Jim | last post: by
3 posts views Thread by David Groom | last post: by
1 post views Thread by Rob Meade | last post: by
3 posts views Thread by rob c | last post: by
5 posts views Thread by Dave Rado | last post: by
3 posts views Thread by JCCDevel | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.