473,320 Members | 1,848 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,320 software developers and data experts.

Is it safe to reuse control names in text fields?

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.
Jul 20 '05 #1
9 2077
/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#submit-format> once
again.

--
Stanimir
Jul 20 '05 #2

"Paul Morrow" <pm****@yahoo.com> wrote in message
news:65**************************@posting.google.c om...
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=value1&samename=value2&samename=value3&o thername=...

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.

Jul 20 '05 #3
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.

Jul 20 '05 #4
> (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.
Jul 20 '05 #5
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
Jul 20 '05 #6
/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#submit-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
Jul 20 '05 #7
Stanimir Stamenkov <s7****@netscape.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#submit-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

Jul 20 '05 #8
/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 'HTMLFormElement.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 'HTMLFormElement.elements' to
build the submit data, therefore I get totally unpredictable
results. But I'm getting off-topic here.

--
Stanimir
Jul 20 '05 #9
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).
Jul 20 '05 #10

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

5
by: David Gray | last post by:
Greetings all, How can I use ADODB to return all tables in an access DB chosen by the user? I'm able so far to select the DB file and build up my connect string, but I would like to offer a...
15
by: Paul Paterson | last post by:
I am trying to find a way to mimic by-reference argument passing for immutables in Python. I need to do this because I am writing an automated VB to Python converter. Here's an example of the VB...
1
by: Michael | last post by:
Hi All, I've finally getting into .NET and have a question for you all. I'm creating an app that needs to insert user data into a word doc. One way I thought of doing this was to save the Word...
5
by: Cro | last post by:
Hello Access Developers, I'd like to know if it is possible to perform a count in an expression that defines a control source. My report is based on a query. In my report, I want a text box to...
3
by: Simon | last post by:
Hi all, I'm hoping that some of you clever chaps could offer me some advice on code reuse. You see, whenever I make applications, I typically only find very limited
2
by: GingerNinja | last post by:
Hi, I'm working on a web control at the moment which creates a simple form with some fields and some labels, all on one line. The output is fine and everything is ok, however I want to control...
10
by: Vinay | last post by:
Hi, Is there a limit on maximum number of columns in listview control ? I am finding: In a listview control (Report Format) I am displaying a record with 400 fields. I am creating its column...
1
by: =?Utf-8?B?am9uZWZlcg==?= | last post by:
I keep getting the message after I converted a regular aspx page to now be based on a master page: "Only Content controls are allowed directly in a content page that contains Content controls."...
21
by: giandeo | last post by:
Hello Experts. Is it possible to retrieve the value from a populated pull down menu from a database and then use that value to access the same database to get the related fields. Example: ...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: jfyes | last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
0
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.