Is it safe to reuse control names in text fields?

[Paul Morrow]

I have seen the technique where a number of rows in a database are
displayed in an html table so that each column of each row is
editable. They use a single form surrounding the table, where each
field in any given column has the same control name. So for example,
in the last_name column, every row in the table would contain an input
field (of type "text") with the name "last_name" .

Is this safe to do? I know that multiple radio buttons in a single
form may have the same control name, but (according to the spec) text
fields should be uniquely named.

The author of this technique is relying on these fields to be passed
as an array to the form processor (cgi script or whatever), but can
this behavior truly be relied upon? If so, will the values always be
in the same order as they appear in the form?

Thanks.

[Stanimir Stamenkov]

/Paul Morrow/:

Is this safe to do? I know that multiple radio buttons in a single
form may have the same control name, but (according to the spec) text
fields should be uniquely named.
Where did you read text fileds should be uniquely named? Also the
term "should" doesn't imply requirement.
The author of this technique is relying on these fields to be passed
as an array to the form processor (cgi script or whatever), but can
this behavior truly be relied upon? If so, will the values always be
in the same order as they appear in the form?

Yes, yes. Refer to
<http://www.w3.org/TR/html4/interact/forms.html#subm it-format> once
again.

--
Stanimir

[Harlan Messinger]

"Paul Morrow" <pm****@yahoo.c om> wrote in message
news:65******** *************** ***@posting.goo gle.com...

I have seen the technique where a number of rows in a database are
displayed in an html table so that each column of each row is
editable. They use a single form surrounding the table, where each
field in any given column has the same control name. So for example,
in the last_name column, every row in the table would contain an input
field (of type "text") with the name "last_name" .

Is this safe to do? I know that multiple radio buttons in a single
form may have the same control name, but (according to the spec) text
fields should be uniquely named.

In my experience, it *works* to have multiple text fields with the same
name. All the non-empty ones are submitted with the form:

... &samename=value 1&samename=valu e2&samename=val ue3&othername=. ..

Whether it's *safe*, I don't know, but I believe it is.

According to the W3C, "The control names/values are listed in the order they
appear in the document."

This doesn't necessarily helpy you, though, because it doesn't tell you what
happens with fields that were left empty. Active Server pages will omit
them. If you don't permit empty fields, you're in better shape, but then you
have to check your server software, first to make sure that it *will*
provide you with the individual values in an array, and second, to make sure
that it leaves the order of the array elements unchanged.

[Alan J. Flavell]

On Fri, 23 Apr 2004, Paul Morrow wrote:

I have seen the technique where a number of rows in a database are
displayed in an html table so that each column of each row is
editable. They use a single form surrounding the table, where each
field in any given column has the same control name. So for example,
in the last_name column, every row in the table would contain an input
field (of type "text") with the name "last_name" .

Is this safe to do? I know that multiple radio buttons in a single
form may have the same control name,
Absolutely. It's by having them the same name, that you define them
to be members of the same exclusive group. If they have a different
name, then they form a different exclusive group. But that's a
peculiarity of radio buttons, it doesn't extend to other kinds of
control.
but (according to the spec) text
fields should be uniquely named.
Where did you get that from? You could be right, but I've reviewed
http://www.w3.org/TR/REC-html40/inte...ms.html#h-17.2
to see whether I missed something, and I can't see it.
The author of this technique is relying on these fields to be passed
as an array to the form processor (cgi script or whatever),
That's not what happens at the actual submission time (multiple
name=value pairs are submitted as, well, multiple name=value pairs),
but it's convenient for the server-side CGI library to reformat that
for the application programmer.
but can this behavior truly be relied upon?
My answer would be "yes".
If so, will the values always be
in the same order as they appear in the form?

The HTML specification answers that in the positive (see 17.13.4).
Personally I'm not sure I'd want to be dependent on it; I don't think
that earlier HTML specs actually specified this. Disclaimer: I
haven't studied the ordering of form submission parameters myself,
across a wide range of browsers, in any detail.

A word of warning, anyway: if you -do- want to rely on this, then take
care that your CGI library also guarantees it. The natural way to
work with CGI.pm in Perl makes use of a "hash", which loses the
ordering of the different keys (names), for example.

It might be better if you went into a bit more detail of _what_ you
want to achieve (rather than about how you intended to implement it, I
mean), then maybe someone could suggest a more resilient way of
approaching the requirement.

[Paul Morrow]

> (according to the spec) text

fields should be uniquely named.
I'm sorry... I'm sure that I read this in some official documentation
years ago, but it's clearly not the case in the w3c standard. I do
see it mentioned all over the place though in 'tutorials' from
unofficial sites.
this behavior truly be relied upon? If so, will the values always be
in the same order as they appear in the form?

What I'm wanting to do is basically what I described in the original
post. I want to have an html table which represents a database table,
where each cell of the (html) table corresponds with a field from a
record in the database table. Each cell should be editable, so we're
talking about a single large form with lots of <input> elements (for
simplicity, let's assume they're all text fields). All input elements
under a single column would have the same control name, so when my
script processes the form submission, it would receive N arrays, one
for each column of the table. Each array would contain R elements,
one for each row of the table. So last_name[0] would be the value of
the last_name field for row 0, age[12] would be the age in row 12,
etc.

So the ordering of the elements in each array is critical (!) If some
browser decides to send the column (field) values back in some
arbitrary order, I would end up corrupting my database table.

[Alan J. Flavell]

On Fri, 23 Apr 2004, Paul Morrow wrote:

for each column of the table. Each array would contain R elements,
one for each row of the table. So last_name[0] would be the value of
the last_name field for row 0, age[12] would be the age in row 12,
etc.

So the ordering of the elements in each array is critical (!)
I think I would arrange to include a number in the names of the fields
when writing the form. Surely it can't be so hard to set
name="last-name-001", name="last-name-002" etc for the sequential
fields? (Start at last-name-000 if you're a mathematician, that's OK
by me ;-)
If some browser decides to send the column (field) values back in
some arbitrary order, I would end up corrupting my database table.

I'd say the prime rule of processing forms input is to be prepared for
anything. I've seen just to many bizarre examples of form submissions
scrambled by this or that browser, and that's not counting jokers who
are deliberately testing you out. Verify everything on the server
side before committing it, don't risk damaging the database as a
result of defective input, but do be reasonably apologetic to the user
when rejecting their submission, since some of the things that
browsers get up to are really not their fault.

Just as a general remark, not specific to your present requirement -
The nice approach is to re-write the partially-accepted form from the
server side, with all the input pre-filled that you previously
verified, and distinctive markers alongside the fields that had to be
rejected (red stars seem to be popular), to give them a chance to
correct it. CGI.pm makes this kind of thing easy, if you're scripting
in Perl, but that side of things is really off-topic for *html and
would be better discussed on *cgi (beware the automoderator bot).

good luck

[Stanimir Stamenkov]

/Stanimir Stamenkov/:

/Paul Morrow/:

The author of this technique is relying on these fields to be passed
as an array to the form processor (cgi script or whatever), but can
this behavior truly be relied upon? If so, will the values always be
in the same order as they appear in the form?

Yes, yes. Refer to
<http://www.w3.org/TR/html4/interact/forms.html#subm it-format> once again.

I have to correct myself - seems like it is not well specified and
the behavior is really undefined. The only reliable way I can think
of is the one proposed by Alan Flavell - using number suffixes in
the field names.

--
Stanimir

[Jukka K. Korpela]

Stanimir Stamenkov <s7****@netscap e.net> wrote:

/Stanimir Stamenkov/:

/Paul Morrow/:

The author of this technique is relying on these fields to be
passed as an array to the form processor (cgi script or whatever),
but can this behavior truly be relied upon? If so, will the values
always be in the same order as they appear in the form?
Yes, yes. Refer to
<http://www.w3.org/TR/html4/interact/forms.html#subm it-format> once
again.

I have to correct myself - seems like it is not well specified and
the behavior is really undefined.

Sorry, I haven't read the thread very carefully, but it seems to me that
there is a minor confusion here, though basically just in a matter of
principle:

The HTML specifications say how the form field contents are passed as
name=value pairs. There is no "array" concept involved, and if some name
parts are of the form foo[index], then that's fine by HTML rules but
treated just as strings of characters - it is up to the form processor to
intepret them as indexed variables, or whatever. I don't think think
there's any fundamental doubt about these principles.

The same name can be used for different fields, and sometimes needs to be
used. But this may cause some practical problems:

According to the specifications, the order of the fields in form data is
the same as the order of fields in the form (in HTML markup). This is
well defined, not undefined. But on the practical side, it is not wise to
rely on browsers getting this right. Even if they worked OK, such
reliance would create unnecessary connections between the exact markup
and the form processing. Some day someone might reorganize the form
without realizing that the processor needs to be changed too - after all,
he just changed the order of some fields! (Maybe even in a manner which
does not change visual appearance, if CSS is used.)

In the special cases where the same name _needs_ to be used, as for a set
of radio buttons in a group, don't rely on any particular order in the
form data. (And for a radio button group, there will be one name=value
part originating from it anyway.)

When it is clear that the order is insignificant, as for any normal set
of checkboxes, you can use the same name for convenience.
The only reliable way I can think
of is the one proposed by Alan Flavell - using number suffixes in
the field names.

And this covers the situation where the order of similarly-name fields
might matter. Of course, the suffixes could be anything that can be
conveniently handled in the processor, not necessarily number-like.

--
Yucca, http://www.cs.tut.fi/~jkorpela/
Pages about Web authoring: http://www.cs.tut.fi/~jkorpela/www.html

[Stanimir Stamenkov]

/Jukka K. Korpela/:

The HTML specifications say how the form field contents are passed as
name=value pairs. There is no "array" concept involved...
That's o.k. I think we all understand it.
According to the specifications, the order of the fields in form data is
the same as the order of fields in the form (in HTML markup). This is
well defined, not undefined.
That's something I've ever thought is well defined but now I haven't
found it in the HTML specification. Could you give me a reference?

In my experience, I've observed this expected behavior from the
different browsers I've used, but:
But on the practical side, it is not wise to
rely on browsers getting this right.

I've just got hit by such an issue - with Mozilla I got unexpected
result when I dynamically rearrange the elements with a script.
Every rearranged form element seems to fall at the end of the
collection represented by the 'HTMLFormElemen t.elements' DOM
property, while the element itself is not at the end of the form
elements in the document tree.

Seems Mozilla traverses that property 'HTMLFormElemen t.elements' to
build the submit data, therefore I get totally unpredictable
results. But I'm getting off-topic here.

--
Stanimir

[Alan J. Flavell]

On Mon, 26 Apr 2004, Stanimir Stamenkov wrote:

That's something I've ever thought is well defined but now I haven't
found it in the HTML specification. Could you give me a reference?

Amazing as it might seem, it's in the HTML4.01 specification, under
the topic of forms, under the subtopic of form submission...

See 17.13.4 Form Content Types, item:
application/x-www-form-urlencoded , bullet point 2.

The control names/values are listed in the order they appear in the
document.

And for multipart/form-data , just a few lines later:

The parts are sent to the processing agent in the same order the
corresponding controls appear in the document stream

To the best of my recollection, HTML4 was the first specification
which codified this detail of the behaviour (feel free to check for
yourself).

As I've said before, I don't think it's a very resilient technique to
make oneself reliant on browsers actually conforming to this detail; I
would try to avoid it myself (except perhaps for Q&D implementations
that are for, effectively, small intranet use, but then we're no
longer really talking about the WWW).