Read form "name" attribute when it contains form field with name "name"

[Pavils Jurjans]

Hello,

I have bumped upon this problem: I do some client-side form processing
with JavaScript, and for this I loop over all the forms in the
document. In order to identify them, I read their "name" property
(which sources from "name" HTML attribue). The problem is, that if the
form contains form control named "name", it overwrites the form name
property. In fact, I'm quite surprised that it's so easy to spoil any
of the form object properties - the form just needs to contain a field
named, say, "onsubmit", and - voila - it's done! Also, if the form
contains field "name", then attempting to assign another name to the
form object will result in error. Quite lame, if you ask me... The
field names shouldn't really matter.
Is there any other alternative way to read and write the form object
properties, if their name conflicts with the form field names?

Thank you,

Pavils

 

[Erwin Moller]

Hello,

I have bumped upon this problem: I do some client-side form processing
with JavaScript, and for this I loop over all the forms in the
document. In order to identify them, I read their "name" property
(which sources from "name" HTML attribue). The problem is, that if the
form contains form control named "name", it overwrites the form name
property. In fact, I'm quite surprised that it's so easy to spoil any
of the form object properties - the form just needs to contain a field
named, say, "onsubmit", and - voila - it's done! Also, if the form
contains field "name", then attempting to assign another name to the
form object will result in error. Quite lame, if you ask me... The
field names shouldn't really matter.
Is there any other alternative way to read and write the form object
properties, if their name conflicts with the form field names?

Thank you,

Pavils

Hi Pavils,

It only happens when you read over all properties you can find in the
document.
Bad habbit.

Try looping over this:
document.forms

it returns zero forms, one form, OR an array of forms.

In case of an array:
oneForm = document.forms[X];

where X is an index. (0 for first form, 1 for second, etc)

from there on:
oneForm.name.value will return the value of the element with the name "name"
in the specified form.

Hope that helps.

Regards,
Erwin Moller

 

[Michael Winter]

Pavils Jurjans wrote:

[snip]

In order to identify [the forms], I read their "name" property
(which sources from "name" HTML attribue). The problem is, that if the
form contains form control named "name", it overwrites the form name
property.

This can happen in any situation where the object model for a user
agent exposes elements via some kind of shortcut. Forms and images can
be referenced directly through the document object. Form controls
through a form object. Microsoft also think it a good idea to
reference elements using their id values through the global object.

In fact, I'm quite surprised that it's so easy to spoil any
of the form object properties

I personally think it's a mistake on the part of the browser vendors.
Note that none of this behaviour is standardised, but parts have
become a de facto standard.

[snip]

Is there any other alternative way to read and write the form object
properties, if their name conflicts with the form field names?

There are two solutions, but neither are necessarily what you're
looking for.

1) Don't use the name attribute to identify the form. That
mechanism was labeled a compatibility feature a long time
ago. For instance, XHTML Strict has removed the name attribute
from a number of elements, including FORM (but not form
controls). Instead, use the id attribute. Of course, you'll
still run foul of the problem if you have an 'id' control.
2) Change the capitalisation of the form control. ECMAScript is,
after all, case-sensitive.

If IE isn't a concern, which isn't likely, a third possible solution
which would require changes to neither your mark-up nor server-side
code is the use of the getAttribute method. However, I haven't tested
whether that's viable across a range of user agents (though it does
work in Firefox).

The reason why it doesn't work in IE (and Opera, since it tries to
emulate some of IE's object model) is that Microsoft decided to flout
the W3C DOM again and allow getAttribute to return anything (function
references to listeners, object references to elements, etc.) rather
than just the string values of attributes.

Good luck,
Mike

 

[Pavils Jurjans]

Hi Michael,

Thanks for understanding the issue and writing through answer. I was
thinking about using the getAttribute, too, but found out that it's
not behaving as normal XML method, but is actually repeating the DOM
call.

Just so that noone thinks I'm doing something wrong (ie, Erwins
comment was calling a bad habbit something I don't do, plus providing
incorrect info on document.forms. Sometimes it helps to read
carefully.), here's a code for testing:

<html>
<head>
<title> Form propery reading </title>

<script>
function runMe() {
var f = document.forms[0];
var ptyName = "action"; // "name"

alert(f[ptyName]);
alert(f.getAttribute(ptyName));
}
</script>

</head>

<body onload="runMe()">

<form name="MyForm" action="HereWeGo.asp">
<input type="text" name="name" value="MyTextField"/><br/>
<input type="text" name="action" value="MyActionField"/>
</form>

<input type="button" onclick="runMe()" value="Test"/>

</body>
</html>


As you could see, whenever you have a form control named just like one
of about 130 properties of the form object in DOM (it's in MSIE6.
There are about 100 in Firefox.), you make it impossible to read the
corresponding form property value, because silly shortcuts to from
controls plainly overwrites it. Very stupid, and the worst thing is
noone is about to correct this OOP violation. Luckily, Firefox doesn't
spoil the getAttribute method, but that doesn't help in MSIE case.

Pavils.