 |
Chapter 17 Forms and Form Elements |
 |
|
Chapter 17 Forms and Form Elements |
|
Two other properties shared by all form element objects are name and value. When a form is submitted, the user's input data is passed to the web server in the form of name/value pairs, and these properties specify the name under which each element's data is submitted and the value that is submitted for that element. The name property is a read-only string; its value is specified by the NAME attribute of the HTML tag that defined the form element. This NAME attribute is optional, but data from an element cannot be submitted unless it is specified. In the next subsection, we'll see another use of the NAME attribute.
The value property is similar to the name property. This property is a read/write string for all form element objects, and it contains the data that is transferred over the network when the form is submitted. The initial value of the value property is, logically enough, usually specified by the VALUE attribute of the HTML tag that defined the form element. For some objects, however, the initial value is specified in some other way.
The value property contains a string value for all form elements. Because of the automatic data conversion performed by Navigator, you can assign a value or object of any type to the value property and it will automatically be converted to a string. Unfortunately, a limitation in Internet Explorer 3.0 does not allow objects to be assigned to the value property. In order to do this you must explicitly convert the object to a string; you cannot rely on automatic conversion as you can with Navigator. Thus, if you wanted to display the current date and time in an input field of a form, the following code would not work in IE 3.0:
today =index.html new Date(); document.myform.date.value = today;
today =index.html new Date(); document.myform.date.value = "" + today;
Not all uses of the value property are obvious at the first glance. For Text and TextArea objects, the value property is simply the string contained in the input field. Setting the value property of these objects changes the text that those input fields display. For Button, Reset, and Submit objects, however, the value property contains is the text that is displayed by the push-button. Although the property is read/write, changing it will not change the text that appears in the button (at least not on all platforms). Also, the value of Button and Reset objects is never actually submitted with the form that contains them. (The value of a Submit object is submitted only when that Submit object was the one that caused the form to be submitted--this allows a CGI script to determine how the form was submitted in cases where there is more than one way to do so.)
The value property for Checkbox and Radio objects is also a little bit tricky. Since these objects represent toggle buttons in an HTML form, you might expect their value property to indicate the state of the button--i.e., to be a Boolean value that indicates whether the toggle button is checked or not. In fact, though, it is the checked property of these objects that indicates what state they are in. The value property, as always, is the string value that is submitted with the form if the Checkbox or Radio object is checked when the form is submitted. It should be set to some string that is meaningful to the CGI script that will receive the form submission.
The Select object is another unusual case. It displays a list or drop-down menu of options and allows the user to select one or more of them. These options are not specified by the <SELECT> tag, but by a separate <OPTION> tag, so it turns out that the Select object actually has no value property, and is an exception to the rule above that all form element objects have a property by this name. Since the VALUE attribute belongs to the <OPTION> tag, the value property belongs to the Option object. Now, you might expect that, like the Text and Button objects, the value property of the Option object would specify the text that is displayed to the user in the list or drop-down menu. In fact, though, this is not how it is done. The text displayed for an Option is meant to be a verbose, human-readable string, and this is not ideal for processing by a CGI script. The text property of the Option object specifies the string that the user sees, and the value property specifies the (usually terser) string submitted if the option is selected when the form is submitted.
While we are discussing the Select and Option objects, it should be noted that these differ in a number of ways form other form element objects. First, note that the Option object is not itself a form element--it is an object contained by a Select object. The Select object is the only form element object that contains other objects. They are contained in its options[] array, so you may end up referring to individual Option objects with very long expressions like the following:
document.forms[0].elements[1].options[2]
The second unique feature of the Option object is that, in Navigator 3.0, they can be dynamically created at run-time. Option objects are created with the Option() constructor function, and can be added to the options[] array of a Select object by simple assignment. This options[] property has several special behaviors itself--if you decrease the value of options.length options will be deleted from the end of the list or drop-down menu displayed by the Select object. Similarly, if you set one of the entries in the options[] array to null, that option will be removed from the list or menu, and the elements following it in the array will be moved down one to fill up the newly vacated array element. For full details, see the Select and Option objects, and their properties in the reference section of this book.
|
 |
|
| Form Elements |  |
Naming Forms and Form Elements |
