Setting the a form's hidden input type

[Jim Tome]

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.MyFor m.CheckBox1.che cked) {
document.MyForm .recipient.valu e = "2";
document.MyForm .submit();
}
}
...

<form name="MyForm" action="http://www.mycompany.c om/cgi/MailMyForm.pl"
method="post" onSubmit="retur n 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.

[Mick White]

Re: Setting the a form's hidden input type

Jim Tome wrote:
[color=blue]
> function CheckBoxes () {
> if (document.MyFor m.CheckBox1.che cked) {
> document.MyForm .recipient.valu e = "2";
> document.MyForm .submit();
> }
> }
> ..
>
> <form name="MyForm" action="http://www.mycompany.c om/cgi/MailMyForm.pl"
> method="post" onSubmit="retur n CheckBoxes()">
>
> <input name="CheckBox1 " type="checkbox" value="yes">
> ..
> </form>[/color]

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

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

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

[Michael Winter]

Re: Setting the a form's hidden input type

On Thu, 06 May 2004 15:19:23 GMT, Mick White
<mwhite13@BOGUS rochester.rr.co m> wrote:

[snip]
[color=blue]
> <input name="CheckBox1 " type="checkbox" value="yes"
> onclick='recipi ent.value=this. checked?"2":"1" '>[/color]

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.f orm.elements['recipient'].value=this.che cked?'2':'1'"

Probably best in a function.

Mike

--
Michael Winter
M.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Jim Tome]

Re: Setting the a form's hidden input type

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 <mwhite13@BOGUS rochester.rr.co m> said:
[color=blue]
> Jim Tome wrote:
>[color=green]
>> function CheckBoxes () {
>> if (document.MyFor m.CheckBox1.che cked) {
>> document.MyForm .recipient.valu e = "2";
>> document.MyForm .submit();
>> }
>> }
>> ..
>>
>> <form name="MyForm" action="http://www.mycompany.c om/cgi/MailMyForm.pl"
>> method="post" onSubmit="retur n CheckBoxes()">
>>
>> <input name="CheckBox1 " type="checkbox" value="yes">
>> ..
>> </form>[/color]
>
> Why not get rid of the function, and use the onclick event handler of
> the checkbox in its stead?
>
> <form action="http://www.mycompany.c om/cgi/MailMyForm.pl"
> method="post" >
> <input type="hidden" name="recipient " value="1">
> <input name="CheckBox1 " type="checkbox" value="yes"
> onclick='recipi ent.value=this. checked?"2":"1" '>
>
> However you need to be certain that the user has javascript enabled.
> Mick[/color]

[Mick White]

Re: Setting the a form's hidden input type

Michael Winter wrote:
[color=blue]
> On Thu, 06 May 2004 15:19:23 GMT, Mick White
> <mwhite13@BOGUS rochester.rr.co m> wrote:
>
> [snip]
>[color=green]
>> <input name="CheckBox1 " type="checkbox" value="yes"
>> onclick='recipi ent.value=this. checked?"2":"1" '>[/color]
>
>
> 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.f orm.elements['recipient'].value=this.che cked?'2':'1'"
>
> Probably best in a function.
>
> Mike
>[/color]
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

[Michael Winter]

Re: Setting the a form's hidden input type

On Thu, 06 May 2004 16:07:47 GMT, Mick White
<mwhite13@BOGUS rochester.rr.co m> wrote:
[color=blue]
> Michael Winter wrote:
>[color=green]
>> On Thu, 06 May 2004 15:19:23 GMT, Mick White
>> <mwhite13@BOGUS rochester.rr.co m> wrote:
>>
>> [snip]
>>[color=darkred]
>>> <input name="CheckBox1 " type="checkbox" value="yes"
>>> onclick='recipi ent.value=this. checked?"2":"1" '>[/color][/color][/color]

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

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

Mike

--
Michael Winter
M.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Mick White]

Re: Setting the a form's hidden input type


[color=blue]
> On Thu, 06 May 2004 16:07:47 GMT, Mick White
> <mwhite13@BOGUS rochester.rr.co m> wrote:[/color]
[color=blue][color=green][color=darkred]
>>> [snip]
>>>
>>>> <input name="CheckBox1 " type="checkbox" value="yes"
>>>> onclick='recipi ent.value=this. checked?"2":"1" '>[/color][/color]
>
>
> [snip]
>[/color]
Michael Winter wrote:[color=blue]
> All Mozilla-based browsers will fail with unqualified references like
> the above.
>
> Mike
>[/color]

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

[Grant Wagner]

Re: Setting the a form's hidden input type

Michael Winter wrote:
[color=blue]
> On Thu, 06 May 2004 16:07:47 GMT, Mick White
> <mwhite13@BOGUS rochester.rr.co m> wrote:
>[color=green]
> > Michael Winter wrote:
> >[color=darkred]
> >> On Thu, 06 May 2004 15:19:23 GMT, Mick White
> >> <mwhite13@BOGUS rochester.rr.co m> wrote:
> >>
> >> [snip]
> >>
> >>> <input name="CheckBox1 " type="checkbox" value="yes"
> >>> onclick='recipi ent.value=this. checked?"2":"1" '>[/color][/color]
>
> [snip]
>[color=green]
> > I am not sure which browsers would fail. None of my current crop, each
> > is tolerant of my miscoding!!.[/color]
>
> All Mozilla-based browsers will fail with unqualified references like the
> above.
>
> Mike[/color]

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="recipi ent.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 <gwagner@agrico reunited.com>

* Client-side Javascript and Netscape 4 DOM Reference available at:
*

http://devedge.netscape.com/library/manuals/2000/javascript/1.3/reference/frames.html

* Internet Explorer DOM Reference available at:
*

http://msdn.microsoft.com/workshop/author/dhtml/reference/dhtml_reference_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

[Michael Winter]

Re: Setting the a form's hidden input type

On Thu, 06 May 2004 19:34:29 GMT, Grant Wagner
<gwagner@agrico reunited.com> wrote:

[snip]
[color=blue]
> 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="recipi ent.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.[/color]

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.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Michael Winter]

Re: Setting the a form's hidden input type

On Thu, 06 May 2004 18:56:01 GMT, Mick White
<mwhite13@BOGUS rochester.rr.co m> wrote:

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

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.
[color=blue]
> I'm not which of these browsers are Mozilla based or not.[/color]

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

Mike

--
Michael Winter
M.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Mick White]

Re: Setting the a form's hidden input type

Michael Winter wrote:
[color=blue]
> On Thu, 06 May 2004 18:56:01 GMT, Mick White
> <mwhite13@BOGUS rochester.rr.co m> wrote:
>
> [unqualified reference from inside a form]
>[color=green]
>> Not to belabour the point, but it works in Netscape 7, IE 5.2, Safari
>> 1.1 and Firefox 1.8 (All Mac)[/color]
>
>
> 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.
>[color=green]
>> I'm not which of these browsers are Mozilla based or not.[/color]
>
>
> Only Netscape, as far as I'm aware, though Firefox (don't you mean 0.8?)
> is Mozilla Firefox.
>
> Mike[/color]

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.formNa me.elementName. elementProperty

Mick

[Michael Winter]

Re: Setting the a form's hidden input type

On Thu, 06 May 2004 23:00:34 GMT, Mick White
<mwhite13@BOGUS rochester.rr.co m> wrote:

[snip]
[color=blue]
> Is the dot syntax deprecated or is this a MS thing ?
> document.formNa me.elementName. elementProperty[/color]

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.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[Richard Cornford]

Re: Setting the a form's hidden input type

Mick White wrote:[color=blue]
> Michael Winter wrote:[color=green][color=darkred]
>>>> Mick White wrote:
>>>>> <input name="CheckBox1 " type="checkbox" value="yes"
>>>>> onclick='recipi ent.value=this. checked?"2":"1" '>[/color][/color][/color]
<snip>[color=blue][color=green]
>> All Mozilla-based browsers will fail with unqualified references
>> like the above.[/color][/color]
<snip>[color=blue]
> 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.[/color]

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.