Radio buttons do not appear checked

[Phil Powell]

<b>Agency 4</b>
<input type="radio" name="permissio n[4]" value="1" checked> Yes
<input type="radio" name="permissio n[4]" value="0" > No
<br>
<b>Agency 5</b>
<input type="radio" name="permissio n[5]" value="1" checked> Yes
<input type="radio" name="permissio n[5]" value="0" > No
<br>
I have it set up this way but upon viewing in the browser none of the
radio buttons appear checked.

By the way the radio button names MUST remain in the PHP array format
as they will be referenced EXACTLY like that by PHP on the server end.
Sorry can't change that.

What can I do?

Phil

[Geoff Berrow]

I noticed that Message-ID: <72************ **@merlyn.demon .co.uk> from Dr
John Stockton contained the following:

if (box.checked == false) box.checked = true;

Unless you feel that false might have been redefined, there is no need
to compare with false; there is a NOT operator.

if (!box.checked) box.checked = true;

There may be no need to test that it is not checked before checking it.

Well that's what you get for nicking bits of code. ;-)

Honestly John, that problem drove me up the wall - I was just happy to
get it working. I had my own code (probably equally as bad) but
scrapped it for something I found on the 'net to get it working. I
guess my own would have worked had I figured out the error.

--
Geoff Berrow
It's only Usenet, no one dies.
My opinions, not the committee's, mine.
Simple RFDs http://www.ckdog.co.uk/rfdmaker/

[VK]

We went deep to the jungles of the abstract programming.
I'm afraid only ECMA/ISO guys (or a 3rd-4th grade Computer Science student
who's forced to remember this stuff) would be capable to finalize the
discussion.

I personally don't see what you see in the 11.2.1 of ECMA specs.
IMHO it just says that the Object.Property construct can be presented
in two ways (or a combination of both):
by literals: ObjectName.Prop ertyName
by expressions: (ExpressionForO bjectName)[ExpressionForPr opertyName]

The same paragraph states that the final result of evaluation in both cases
is an Identifier (I read: "ECMA-compliant identifier"). No mentions anywhere
that such identifier would have more format freedom
than any other identifier.

I still think that 3W did a big boo-boo. Trying to satisfy the wildest
naming desires in their DOM/XML models, they neglected the fact that all
this data
will be inevitable treated by some programming language
(PHP, ASP-VScript, Perl, Java, JavaScript etc.)
based on the much more conservative ISO standards.

IMHO it didn't blow up yet just because of some healthy conservatism
of the programmers' community. If you did programming long enough,
it takes some guts and a good shoot of whisky to create an object
_$$_\u0410\u041 E_
with a property \041F$$_$
But I'm expecting a lot of fun later when programmers will become more dare
and will try to fully use the given naming freedom.
Still would be interesting to know the Final Right Answer...

ECMA 262 Section 7.6 describes the rules that apply whenever the
production - Identifier - is used. However, Section 11.2.1 (Property
Accessors) includes the productions (for bracket notation):-

MemeberExpressi on [ Expression ]
- and -
CallExpression [ Expression ]

- and the algorithm for resolving these property accessors is:-

<quote cite="ECMA 262 3rd Edition Section 11.2.1 Property Accessors">
...
The production MemberExpressio n : MemberExpressio n [ Expression ] is
evaluated as follows:

1. Evaluate MemberExpressio n.
2. Call GetValue(Result (1)).
3. Evaluate Expression.
4. Call GetValue(Result (3)).
5. Call ToObject(Result (2)).
6. Call ToString(Result (4)).
7. Return a value of type Reference whose base object is
Result(5) and whose property name is Result(6).

The production CallExpression : CallExpression [ Expression ] is
evaluated in exactly the same manner, except that the contained
CallExpression is evaluated in step 1.
</quote>

The result of the - Expression - is used as the property name and the
algorithm does not require that string to conform to the rules for -
Identifier - (it doesn't even check).

So, while production rules that resolve to - Identifier - should produce
errors if the character sequence used does not conform to the rules for
Identifier, ECMA Script does allow properties to be created and read
with _any_ name. If the name does not conform to the rules for
Identifier then it is necessary to use bracket notation to access the
property as that side steps the rules for Identifier.

Therefor a conforming ECMA Script implementation must allow properties
to be created and accessed by _any_ name.

And this is a good thing as even the erroneous interpretation of HTML
CDATA attribute values that attempted to place the NAME and ID
restrictions upon them still allowed character that would not be allowed
in an ECMA Script identifier.

The point at which HTML naming is restricted by the desire to script is
when the attribute values represent integer numbers, but that is more a
consequence of the DOM implementation than ECMA Script as HTML
collections make nodes available as both named properties and as integer
indexed members. So an attempt to read a property of a collection that
is named as an integer number stands a very good chance of returning the
wrong node (or just confusing the DOM implementation) .

On the whole, it must be easier to side step the issue by assigning
values to HTML name and ID attributes that are also valid ECMA script
identifiers (indeed that would be the natural thing to do under most
circumstances) but when that is not possible ECMA script is quite
capable of coping with the results (at least under all realistic
circumstances).

Richard.

[Richard Cornford]

"VK" <sc**********@y ahoo.com> wrote in message
news:3f******** *************** @news.freenet.d e...

We went deep to the jungles of the abstract programming.
I'm afraid only ECMA/ISO guys (or a 3rd-4th grade Computer
Science student who's forced to remember this stuff) would
be capable to finalize the discussion. I personally don't see what you see in the 11.2.1 of ECMA specs.
IMHO it just says that the Object.Property construct can be
presented in two ways (or a combination of both):
by literals: ObjectName.Prop ertyName
by expressions: (ExpressionForO bjectName)[ExpressionForPr opertyName] The same paragraph states that the final result of evaluation in
both cases is an Identifier (I read: "ECMA-compliant identifier").
The ECMA Script algorithm states that the final result of the Expression
used in bracket notation is a string representing a property name. I
suspect that you are being confused by the part of Section 11.2.1 that
reads:-

<quote cite="ECMA 262 3rd Edition Section 11.2.1 Property Accessors">
....
The dot notation is explained by the following syntactic conversion:

MemberExpressio n . Identifier

is identical in its behaviour to

MemberExpressio n [ <identifier-string> ]

and similarly

CallExpression . Identifier

is identical in its behaviour to

CallExpression [ <identifier-string> ]

where <identifier-string> is a string literal containing
the same sequence of characters as the Identifier.
....
</quote>

However, this does not mean that the Expression used in bracket notation
must follow the restrictions imposed on Identifier. It states that if
the Expression in a bracket notation property accessor resolves to the
same character sequence used for the Identifier in a dot notation
accessor then the behaviour of the two would be identical.

Because dot notation requires an Identifier to appear to the right of
the dot a property that can be accessed by dot notation must have a name
that satisfies the Identifier rules. That is a syntax rule imposed on
ECMA Script source code, but property access itself is governed by the
algorithm stated in Section 11.2.1 and that algorithm does not impose
any restrictions on the character sequence used.
No mentions anywhere that such identifier would have more
format freedom than any other identifier. <snip>

Section 11.2.1 defines Property Accessors not Identifiers, and places no
restrictions on the character sequence that can be used in a property
name. Dot notation is subject to the rules for Identifier because its
production directly employs the Identifier production, bracket notation
does not draw on the Identifier production so it is only subject to the
rules for Property Accessors; the Expression may result in _any_
character sequence.
Still would be interesting to know the Final Right Answer...

The Property Accessor algorithm is the correct and final answer to the
question of what character sequences may be used as property names in
ECMA Script. It is possible (even probable) that implementations place
some additional restrictions on property names, such as their maximum
length, but ECMA Script does not.

Richard.

[Lasse Reichstein Nielsen]

"VK" <sc**********@y ahoo.com> writes:

I'm afraid only ECMA/ISO guys (or a 3rd-4th grade Computer Science student
who's forced to remember this stuff) would be capable to finalize the
discussion.
I think I qualify. I'm might not be forced to remember it, but I'm way
past 4th grade computer science :)
I personally don't see what you see in the 11.2.1 of ECMA specs.
IMHO it just says that the Object.Property construct can be presented
in two ways (or a combination of both):
by literals: ObjectName.Prop ertyName
by expressions: (ExpressionForO bjectName)[ExpressionForPr opertyName]
It says the
memberExpressio n.Identifier
is evaluated just as
MemberExpressio n[<identifierStri ng>]
where <identifierStri ng> is a string literal containing the string
corresponding to the identifier. This only goes one way. That part makes
no statements about how MemberExpressio n[Expression] is in fact evaluated.
That comes right after.
The same paragraph states that the final result of evaluation in both cases
is an Identifier (I read: "ECMA-compliant identifier").
In ECMA 262, version 3 final (24. March 2000), section 11.2.1? I can't
see that. In fact, there seems to be no occurances of either
"ECMA-compliant" or "compliant identifier".

What I can see is the evaluation of MemberExpressio n[Expression]:
---
1. Evaluate MemberExpressio n.
2. Call GetValue(Result (1)).
3. Evaluate Expression.
4. Call GetValue(Result (3)).
5. Call ToObject(Result (2)).
6. Call ToString(Result (4)).
7. Return a value of type Reference whose base object is Result(5) and
whose property name is Result(6).
---

There is nothing in this definition that prevents Result(6) from being
any string. In fact, since Expression can be a string literal, any
string that has a literal represnetation (they all do) can be used
as a property name.

Looking through ECMA 262 (the one from 1999, not the final version, I
can't stand to read the sans-serif font!) I can't see any definition
of what a legal property name is. What I can see is, as above, that
any string will work, and that anything used as a property will be
converted to a string, so property names are probably strings.
It's not specified explicitly, though. I would call that an oversight,
considering how much detail they go into in other cases.
I still think that 3W did a big boo-boo. Trying to satisfy the wildest
naming desires in their DOM/XML models, they neglected the fact that all
this data will be inevitable treated by some programming language
(PHP, ASP-VScript, Perl, Java, JavaScript etc.)
based on the much more conservative ISO standards.

Not a problem. All collections will have a "namedItem" method that can
be used with a language level string as an argument.

/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.'