radiobuttons and radio groups

[Andy Fish]

Hi,

Can someone explain why this works:

for (i=0; i<document.form1.radiogroup.length; i++) {
var myRadio = document.form1.radiogroup[i];
}

but this does not:

for (i in document.form1.radiogroup) {
var myRadio = document.form1.radiogroup[i];
}

I'm sure this is down to a simple lack of understanding on my part. I have
hunted round all the w3c recommendations for DOM and HTML and the ECMAScript
bindings, but I can't find anything that properly explains the programming
model for radio groups. Have I missed something?

Andy

[Andy Fish]

"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:oe**********@hotpop.com...

"Andy Fish" <aj****@blueyonder.co.uk> writes:

Can someone explain why this works:

for (i=0; i<document.form1.radiogroup.length; i++) {
var myRadio = document.form1.radiogroup[i];
}

but this does not:

for (i in document.form1.radiogroup) {
var myRadio = document.form1.radiogroup[i];
}
How does it not work? Does it give a runtime error and stop, or does it
just not give the result you expect?

I was deliberately not giving all the detail because I think it's clear from
the context what I'm trying to do. What I want to do is iterate through all
the radio buttons in the group.

I'm sure this is down to a simple lack of understanding on my part. I have hunted round all the w3c recommendations for DOM and HTML and the ECMAScript bindings, but I can't find anything that properly explains the programming model for radio groups. Have I missed something?
A radiogroup is not an array. When you use for(..in..), you iterate
through all the visible properties of the object. In a radiogroup
object, there are more visible properties than just the integer named
ones. One of them is the "namedItem" method. When I run the second
example, the one you say doesn't work, the final value of myRadio
is the "namedItem" function.

I'm happy to accept that it's not an array. I understand that it could be an
object with a property called length. However, in that case I can't see how
the square bracket notation in the second example works. I thought that
square brackets applied to an object returned the named properties.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

[Lasse Reichstein Nielsen]

"Andy Fish" <aj****@blueyonder.co.uk> writes:

I was deliberately not giving all the detail because I think it's
clear from the context what I'm trying to do. What I want to do is
iterate through all the radio buttons in the group.
I did assume that some code was missing that would operate on the
myRadio variable. The code you presented would run with no *errors*. I
asked for how the examples failed, mostly to check what you did
expect.
I'm happy to accept that it's not an array. I understand that it
could be an object with a property called length. However, in that
case I can't see how the square bracket notation in the second
example works. I thought that square brackets applied to an object
returned the named properties.

The square bracket notation returns the value of a given property.

If "namedItem" is a property of the object "o", then "o['namedItem']"
will return the value of that property.
If you write
for (var i in o) {
... o[i] ...
}
then you will do something with the values of each property of "o".

The "for(i in obj)" construction iterates throught the names of the
enumerable properties of "obj". All the values that "i" assume are
properties of the object, but some properties are excluded (the
non-enumerable ones).

The enumerable properties of the NodeList (the radio group collection)
differs between browsers.

If I make a form (called "foo") with four radiobuttons in a group
called "bar", and use the following code to show the properties of it:
var x="";for(var i in document.forms.foo.bar) {x+=i+"\n"};alert(x)
then I get the following results.

In Mozilla, I can see the properties: item, length.

In Opera 7, I can see the properties: tags, item, namedItem.

In IE 6, I can see the properties: length, bar, bar, bar, bar. (That
is REALLY spurious, since it claims to have the same property four
times. That is, the for(..in..) construct doesn't work as it should).
In your case, you want to iterate through *some* of the properties of
the collection of radio buttons (the ones that are integers, which are
not enumerable in any browser). For that you cannot use
"for(...in...)", since it iterates through *all* the *enumerable*
properties, but you must count from 0 to length-1 manually.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
Art D'HTML: <URL:http://www.infimum.dk/HTML/randomArtSplit.html>
'Faith without judgement merely degrades the spirit divine.'

[Richard Cornford]

"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:he**********@hotpop.com...
<snip>

... . That is, the for(..in..) construct doesn't work as it should).

<snip>

I would have thought that DOM elements, collections, nodeLists and such
like would be classified as "Host Objects" (ECMA 262 section 4.3.8), in
which case I don't think that there is any defined behaviour for the -
for(var prop in obj) - construct.

Without specified behaviour for - for(var prop in obj) - when applied to
a Host Object any results achieved will be coincidence and it would be
unrealistic to expect them to be consistent across browsers. Try your
test on Opera 6, I doubt that you will even see 'length' enumerated.

Richard.

[Richard Cornford]

"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:d6**********@hotpop.com...
<snip>

... . I still find IE's choice of implementation dependent
behavior highly curious and counterintuitive, when it
allows the for(..in..) construction to give the same value
more than once.

<snip>

Yes it is odd, and unhelpful as I would still expect each property
access by name to return the same object member (probably the first
(whatever that means)). I suspect that this provides additional evidence
for your suggestion of a couple of weeks ago that IE implements its
objects as some sort of list instead of as a HashTable, as a HashTable
could only have one property of the same name.

(You have, of course, realised why I likened trying to help George
Hester to beating your head against a wall (the best part of which is
when you stop) ;-)

Richard.

[Andy Fish]

Thanks for all this comment folks, I certainly have a better understanding
of what's going on now.

to return to one of the questions in my original post, can anybody point me
to a specification that describes the ECMAScript programming model for HTML
form controls - it seems to fall in a gap between the specs for HTML, DOM,
and the language itself.
"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message
news:bh*******************@news.demon.co.uk...

"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:d6**********@hotpop.com...
<snip>

... . I still find IE's choice of implementation dependent
behavior highly curious and counterintuitive, when it
allows the for(..in..) construction to give the same value
more than once.

<snip>

Yes it is odd, and unhelpful as I would still expect each property
access by name to return the same object member (probably the first
(whatever that means)). I suspect that this provides additional evidence
for your suggestion of a couple of weeks ago that IE implements its
objects as some sort of list instead of as a HashTable, as a HashTable
could only have one property of the same name.

(You have, of course, realised why I likened trying to help George
Hester to beating your head against a wall (the best part of which is
when you stop) ;-)

Richard.