|
|
|
 |
Magazine |
| | Community |
| | Workshop |
| | Tools & Samples |
| | Training |
| | Site Info |
 |
 |
||||||||
|
|
||||||||
|
|||||||||
Forms provide an interface for collecting, displaying, and delivering information, and are a key component of HTML. By providing different controls such as text fields, buttons, and checkboxes, forms enhance Web pages with a means to exchange information between a client and a server. The various controls allow authors and users to perform actions, make choices, and quickly identify and enter information. When the form data is submitted to the server- or client-side script, the information can be parsed and cataloged, or redirected in response to the submission. Forms are prevalent throughout all graphics-based operating systems and Web pages.
Web-based forms are supported in most browsers, and including forms in a Web page is relatively straightforward. This overview introduces form controls, discusses form design and accessibility, and provides a first step to submitting and managing form data.
Note Handling form submissions requires knowledge of a programming language such as Perl, C++, or server-side scripting and Active Server Pages (ASP).
Using forms is advantageous for Web sites. Forms are:
The advantages of using forms include ease of implementation and extensibility provided through DHTML. Forms provide a convenient interface for exchanging information between a server and a client, and allow an author to quickly create and distribute an HTML interface to a large audience. With DHTML, Web authors can enhance forms using CSS and client-side scripting languages, such as Microsoft JScript™ and Microsoft Visual Basic® Scripting Edition (VBScript). Applying CSS attributes to forms allows authors to make communications more accessible by using positioning and dynamic styles to increase visibility and make access to controls easier. Combined with robust client-side scripts, forms can be enhanced to provide validation, masking, or even to perform calculations once reserved for the server.
Form controls allow authors to provide Web sites with benefits similar to other graphics-based programming languages. The following table provides a list of the supported form controls, when they were first available in Internet Explorer, what attributes are submitted, and a description.
| Element/Control | Availability | Submitted | Description |
|---|---|---|---|
| BUTTON | 4.0 | NAME, VALUE | Specifies a rich button control that can include DHTML. When submitted, Internet Explorer 4.0 submits the innerText, and Internet Explorer 5 and later submits the NAME/VALUE pair. |
| HTMLAREA | 5 | NAME, VALUE | Specifies a rich text control that allows users to resize objects, change text and fire events. When the HTMLAREA object is submitted, the ASCII equivalent of the value is sent. |
| INPUT_button | 3.0 | NAME, VALUE | Specifies that the INPUT object is rendered as a button. Events such as onclick can be included with the button to provide action when it is clicked. |
| INPUT_checkbox | 3.0 | NAME, VALUE | Specifies that the INPUT object is rendered as a checkbox. The checkbox is useful for selecting multiple groups of topics (for example, selecting favorite magazines) and Boolean decisions (for example, adding your e-mail to the mailing list). Events such as onclick can be used in conjunction with the checked property to determine conditions (for example, displaying a hidden object). |
| INPUT_file | 4.0 | NAME, VALUE(encoded) | Specifies that a nonscriptable text field and browse button are rendered. The ENCTYPE attribute for a form must be set to multipart/form.data in order for this control to properly work. For security reasons, the VALUE attribute is not accessible in script on the client. |
| INPUT_hidden | 3.0 | NAME, VALUE | The hidden control is useful for submitting additional information that does not need to be displayed to the user. |
| INPUT_image | 3.0 | NAME | Specifies that a submit control is rendered as an image. The image control is a useful alternative to using buttons. When the image control is clicked, it is the only image control that is submitted for the form. In addition, an image control is only submitted if the NAME attribute is specified. |
| INPUT_password | 3.0 | NAME, VALUE | Specifies that a text field that is masked with asterisks is rendered. The password field is useful on the client to shield private information from anyone looking at the same screen. |
| INPUT_radio | 3.0 | NAME, VALUE | Specifies that a radio control is rendered. The radio control is useful for selecting one item from a set. Selecting one radio control clears any other radio controls with the same NAME attribute value. |
| INPUT_reset | 3.0 | Specifies a button is rendered that resets all form values. | |
| INPUT_submit | 3.0 | NAME, VALUE | Specifies a button is rendered that sends all the information for a particular form to the script or program specified in the ACTION attribute.
The METHOD attribute specifies the way the form information is delivered.
Submit controls are only sent if the NAME attribute is defined. If more than one submit control exists in a particular form, only the control that is clicked is sent. |
| INPUT_text | 3.0 | NAME, VALUE | Specifies that a single-line text field is rendered. |
| OPTION | 3.0 | VALUE, TEXT | An OPTION object specifies an item in a SELECT control. |
| SELECT | 3.0 | NAME, OPTION(selected) | Specifies that a drop-down list or list box is created, comprised of included OPTION elements, or created dynamically using the options collection and add method. A list box is created by specifying a value greater than 1 for the SIZE attribute. Multiple options in a list box can be selected by including the MULTIPLE attribute. If the MULTIPLE attribute is included, a list box is created. If the SIZE and MULTIPLE attributes are not present, a drop-down list is created. |
| TEXTAREA | 3.0 | NAME, VALUE | Specifies a multi-line text field is rendered. The VALUE of the TEXTAREA is equivalent to the innerText property, and is located between the opening and closing tags. |
To implement forms on a Web site, you must first determine the need for the FORM element. The FORM element is necessary for submitting form controls to a server. When a form is submitted, only the name/value pairs for the controls within the submitted FORM element are sent. The FORM element is not necessary if form controls are being used for only client-side scripting. However, other browsers may require the element before the controls are rendered.
When using the FORM element, the ACTION and METHOD attributes are used to specify how the data in the form controls is delivered, and the destination of the data. The two methods used are get and post.
A form action can be any script that is designed to process the delivered information and reply to the HTTP server so results can be returned to the client. The following sample demonstrates the syntax of the FORM element that sends form data as a post transaction to an Active Server Page.
<FORM ACTION = "process.asp" METHOD = "post"> : </FORM>
Form controls are added to Web pages as HTML elements. For example, adding two text fields for the first and last names of visitors only requires the INPUT_text control.
<FORM> First Name: <INPUT TYPE = "text" NAME = "FirstName" > <BR> Last Name: <INPUT TYPE = "text" NAME = "LastName" > </FORM>
When adding controls, it is important to understand the difference between the ID and NAME attributes. Both attributes are accessible via client-side scripting, but only the NAME is passed when the form is submitted. In addition, the ID element can be referred to directly in script while the NAME element must be referred to by including the NAME attribute of the parent form, if the element is a child of a FORM object. For example, if a Web author desires to access the VALUE attributes of the FirstName text field on the client, several considerations have to be taken into account.
<FORM NAME = "Form1"> <INPUT TYPE = "text" ID = "oFirstName" NAME = "FirstName" > </FORM>
var sFirstName = oFirstName.value;
var sFirstName = oFirstName.value;
// Access the VALUE through the form NAME var sFirstName = Form1.FirstName.value; // Access the VALUE through the forms collection using the NAME attribute. var sFirstName = document.forms[0].FirstName.value; // Access the VALUE through the forms collection using the item method. var sFirstName = document.forms[0].items[0].value;
The INPUT_text, INPUT_password, and TEXTAREA controls are useful for submitting name/value pairs. A Web author may desire more specific information or want a more controlled environment for entering information. Ensuring that the correct information is supplied is critical for databases that rely on specific values for queries. It is useful to provide preset values and choices that can be selected when particular information is required.
The SELECT, INPUT_checkbox, and INPUT_radio controls are ideal for selecting preset information and making choices without requiring (though allowing) keyboard input. This makes it easier and faster for users to supply information, and it means that the Web author or system administrator knows the exact value combinations.
The SELECT control is extremely useful for quickly selecting one or more items from a predefined or dynamically constructed list. Implementing the SELECT control is straightforward, but doing something with the control can be aggravating. The SELECT control allows a Web author to choose from several implementations using the SIZE and MULTIPLE attributes.
The three primary incarnations of the SELECT control are illustrated in the following diagram, accompanied by the attribute settings used to achieve the rendered version.
The three different implementations of the SELECT control are a drop-down list, a list box, and a multi-select list box. The OPTION object is used to populate the control. Referring to the selected values requires being able to identify the control and the selected option. To retrieve the selected value, the selectedIndex property is used with the options collection to identify the particular item. For example, the following code contains a sample SELECT control and a few lines of script that use the alert method to display the selected value when the onchange event fires.
<SCRIPT>
function fnShowText(){
/* Use the selectedIndex property of the SELECT control
to retrieve the text from the options collection. */
var sText = oSel.options(oSel.selectedIndex).text;
alert(sText);
}
</SCRIPT>
<SELECT ID = "oSel" onchange = "fnShowText()">
<OPTION>Luna
<OPTION>Saturn
<OPTION>Europa
<OPTION>Io
<OPTION>Jupiter
<OPTION>Monolith
</SELECT>
A somewhat different approach is required to retrieve the selected values from a multi-select list. By iterating through all the options, the selected property can be queried to determine if the option is selected. If so, the current index of the iteration can be used to acquire the text or value of the item. The following sample code demonstrates how this is done.
<SCRIPT>
function fnShowText(){
/* Look through all the options to find selected items. */
for(var i = 0; i < oSel.options.length; i++){
/* Check to see if a particular option is selected */
if(oSel.options(i).selected){
/* Return the selected calue */
alert(oSel.options(i).text);
}
}
}
</SCRIPT>
<SELECT ID = "oSel" MULTIPLE SIZE = "5" onchange = "fnShowText()">
<OPTION>Luna
<OPTION>Saturn
<OPTION>Europa
<OPTION>Io
<OPTION>Jupiter
<OPTION>Monolith
</SELECT>
When a multi-select list is submitted, the items are sent as a comma-delimited list. If a VALUE is not provided for an option, the TEXT is sent instead.
The INPUT_checkbox and INPUT_radio controls provide similar interfaces with different capabilities. When the NAME attributes on two or more INPUT_radio controls are the same, the controls act as a collection. As a collection, only one INPUT_radio control can be checked at a time. Selecting one option at a time makes this control ideal for Boolean choices, or options that have only one possible value.
For example, if an elementary school history teacher wishes to design a multiple choice exam, the choices could be comprised of radio controls. The following sample demonstrates how the INPUT_radio control is implemented. In order to provide LABEL elements, each radio control is given a unique ID, but the NAME attribute is the same so that the controls function as a collection. An INPUT_button object is included to provide the correct answer, and uses an onclick event to verify the checked property of the controls.
<FORM NAME = "Form1"> The first President of the United States was: <TABLE> <tr> <td> <LABEL FOR = "oRadio1">George Washington</LABEL></td> <td><INPUT TYPE = "radio" NAME = "radio1" ID = "oRadio1"></td> </tr> <!-- Place additional choices here --> </TABLE> <INPUT TYPE = "button" VALUE = "Check Answer" onclick = "fnGetAnswer()"> </FORM>
To determine which radio control is selected, the collection is accessed and the checked property is verified.
<SCRIPT>
var aRadio1Answers=new Array("Correct.","Incorrect","Incorrect,"Incorrect");
function fnGetAnswer(){
for(var i=0;i<Form1.radio1.length;i++){
if(Form1.radio1(i).checked){
alert(aRadio1Answers[i]);
}
}
}
</SCRIPT>
On the other hand, if several choices from a group need to be made, then the INPUT_checkbox control can be used. For example, if a teacher wishes to test a student's knowledge about a range of information, the INPUT_checkbox control is preferred for allowing a series of choices to be made. The syntax is the same as the radio control; only the TYPE attribute is different.
Select the inventions that were created before 1500 AD. <FORM NAME="Form1"> <TABLE> <TR> <TD><LABEL FOR = "oInvention1">Crop Rotation (science)</LABEL></TD> <TD><INPUT TYPE= "checkbox" NAME = "invention1" ID = "oInvention1"></td> <!-- Place additional choices here --> </TABLE> <INPUT TYPE = "button" VALUE = "Check Answers" onclick = "fnCheck()"> </FORM>
In this example, the correct values are predetermined. In fact, checking for the correct values is easy. However, it gets a little tricky checking for incorrect values and handling the different cases.
// Preset binary markers for the correct answers.
var aAnswers=new Array(0,1,0,0,0,1,1,0,1,1);
// Total number of correct answers possible.
var iTotalCorrect=5;
// Number of attempts to submit answers.
var iTries=0;
function fnCheck(){
// Increment tries and set correct and incorrect answers to zero.
iTries++;
var iCorrect=0;
var iIncorrect=0;
// Use an array of preset binaries and see if the right control is checked.
for(var i=0;i<Form1.invention1.length;i++){
// If the checkbox is checked and the binary is 1, it is a correct answer.
if((Form1.invention1(i).checked)&&(aAnswers[i]==1)){
iCorrect++;
}
// If the checkbox is checked and the binary is 0, it is an incorrect answer.
if((Form1.invention1(i).checked)&&(aAnswers[i]==0)){
iIncorrect++;
}
}
// If there are fewer correct answers than the total, or there are any incorrect answers
// return the following message.
if((iCorrect0)){
alert("You have some correct and " + iIncorrect + " incorrect answers.");
}
// If there are no incorrect answers, and all the correct answers are chosen, continue.
if((iCorrect==iTotalCorrect)&&(iIncorrect==0)){
// Proceed based on number of attempts.
if(iTries==1){
alert("Congratulations, you got them all right on the first try!");
}
else{
alert("Congratulations. It took " + iTries + " tries.");
}
}
}
Forms can quickly become large and difficult to organize and use. Internet Explorer 4.0 and later supports several features that help authors manage forms, and help users quickly jump to particular places on a form.
The following image depicts how the FIELDSET and LEGEND objects can be used to group INPUT_text and LABEL objects together.
Using the afforementioned enhancements, a form can be organized and accessible to more users. The following code demonstrates how these enhancements are implemented.
<!-- The FIELDSET is a container for the controls. --> <FORM> <FIELDSET STYLE="width: 200;"> <!-- The LEGEND identifies the FIELDSET --> <LEGEND>Accessibility Form</LEGEND> <TABLE> <TR> <TD> <!-- A TABINDEX of -1 specifies this object is skipped. --> <LABEL TABINDEX = "-1" FOR= "oFirstName"> <!-- The acceleration key is underlined for easy identification --> <SPAN STYLE = "text-decoration: underline;">F</SPAN>irst Name </LABEL> </TD> <TD> <!-- The ID is defined for the LABEL, the NAME is provided for form submission --> <INPUT TABINDEX = "1" TYPE = "text" ID = "oFirstName" NAME = "FirstName" ACCESSKEY = "F"> </TD> </TR> </TABLE> </FIELDSET> </FORM>
The AutoComplete feature, available in Internet Explorer 5 and later, provides further enhancements to forms usability. See the Intelliforms Overview for more information.
Text plays an important role in forms, particularly for messages, database queries, or updating content. In addition, managing text is a prerequisite for developing any sort of word processing or data organization, such as with spreadsheets. Since form controls are primarily designed to work with ASCII text, formatting the value within the control is extremely difficult.
The form controls that permit direct user input are the INPUT_text and TEXTAREA objects. As of Internet Explorer 5, the HTMLAREA control allows text input, in addition to allowing users to resize objects and fire events.
The TEXTAREA and HTMLAREA elements are ideal for entering multi-line messages. The size of the TEXTAREA and HTMLAREA are adjustable using the COLS and ROWS attributes. Wordwrap is specified using the WRAP attribute. The following sample code highlights the syntax for a TEXTAREA element using the COLS, ROWS, and WRAP attributes.
<TEXTAREA COLS = "50" ROWS = "10" WRAP = "hard"> ... </TEXTAREA>
Beyond simply entering text messages, the TEXTAREA and HTMLAREA elements are useful for working with raw information provided by the user. For example, if a technical support Web site wants to provide an automated feature that checks for temporary files that can be deleted, they may require a total list of files from a particular directory. An easy and security-conscious way to get this information from the user's hard drive to the Web site would be to simply have the user paste the file list into a TEXTAREA element. Once the file list is provided, the Web site can then proceed to analyze the files in client-side script.
All that is needed to convert the VALUE of the TEXTAREA into a functional list for analysis is a common character. In this case, a line return can be used to parse the VALUE and create an array. The following code demonstrates how this is done.
<SCRIPT>
function fnParseValue(){
var oFileArray = new Array();
oFileArray = oConvert.value.split("\n");
// This returns a script array that can now be sorted or altered.
}
</SCRIPT>
<TEXTAREA onpaste = "fnParseValue()" ID = "oConvert">
Past file list here.
</TEXTAREA>
When a FORM element is submitted, only the controls within the element are sent. There are many different reasons to use forms, but there are only a few directions the information can go. Form submissions can be directed:
Form information can be processed on the client using JScript, VBScript, or any other supported scripting language. Processing form information on the client is useful for any Web-based utility or tool that does not require interaction with the server. If the form data needs to be written to a file or added to a database, then server interaction is most likely required.
The script or application that handles the form submission is specified by the ACTION attribute. This script can be just about any script or application that is supported by the Web server or operating system, and that generates results the client can understand (typically HTML). The scripts that handle form submissions are referred to as Common Gateway Interfaces (CGI). Some languages that CGI scripts are written in are:
Web authors can also use server-side script embedded in the Web document, such as ASP. Server-side script is preprocessed by the Web server and the results are generated in HTML. For example, ASP allows Web authors to use predefined scripting objects and implementations of client-side script to achieve the same results as other CGI-capable languages.
Whether a form is designed to be processed on the client or on the server, the form can always be submitted in one of the following ways.
In addition to using a scripting language, control, or application, forms can also be submitted using the mailto protocol. It is recommended to set the METHOD attribute to post and the ENCTYPE attribute to text/plain on the FORM object when using mailto. To use this protocol, the e-mail message can be constructed within the mailto protocol, or using the e-mail form names. If no names are provided, the information is simply appended to the e-mail body. The e-mail form names are:
Using these particular field names is only practical when the mail path is not constructed in script. The following sample outlines an e-mail form that constructs the form action when the onsubmit event fires.
<FORM METHOD = "get" onsubmit = "fnSetAction()" NAME = "oMailForm"> <LABEL FOR = "oTo"><SPAN>A</SPAN>ddress:</LABEL> <INPUT ACCESSKEY = "A" ID = "oTo" VALUE = "" TYPE = "text" NAME = "recipient"> <BR>& lt;LABEL FOR = "oSubject"> <SPAN>S</SPAN>ubject:</LABEL> <INPUT ACCESSKEY = "S" VALUE = "" ID = "oSubject" TYPE=text name="subject"> <BR> <!-- Repeat for additional fields --> <LABEL FOR=oBody><SPAN>M</SPAN>essage Body:</label> <TEXTAREA TYPE=text ACCESSKEY="M" COLS=40 ROWS=5 ID=oBody TYPE=text NAME="body"> </TEXTAREA> <BR> <BUTTON ACCESSKEY="E" TYPE=submit> Send <SPAN>E</SPAN>mail </BUTTON> <BR> <BUTTON ACCESSKEY="R" TYPE=reset> <SPAN>R</SPAN>eset E-mail Form </BUTTON> </FORM>
<SCRIPT>
if(oMailForm.recipient.value!=""){
var sAction="mailto:" + oMailForm.recipient.value;
if(oMailForm.subject.value!=""){
sAction+="&Subject=" + oMailForm.subject.value;
}
if(oMailForm.cc.value!=""){
sAction+="&cc=" + oMailForm.cc.value;
}
if(oMailForm.bcc.value!=""){
sAction+="&bcc=" + oMailForm.bcc.value;
}
if(oMailForm.body.value!=""){
sAction+="&body=" + oMailForm.body.value;
}
oMailForm.action=sAction;
}
else{
alert("Address required.");
}
}
</SCRIPT>
En route to the CGI script specified by the ACTION, the location of the form data is specified by the METHOD attribute. If the possible value get(deprecated) is used, the form data is appended to the URL and a 4K limit is imposed. However, if the possible value post is used, the form data is sent with the HTTP header without a size limit.
The get possible value is advantageous for debugging scripts or learning how the submission process works. When using the get possible value, the form data can be retrieved in client-side or server-side script by analyzing the href property on the location object. The following sample demonstrates how this information is accessed via script. Consider a form with controls named oFirstName, oLastName, and oPhrase.
var aData=new Array();
function fnInit(){
var sLocation= location.href;
var sData = sLocation.substring(sLocation.indexOf("?") + 1,sLocation.length);
aData = sData.split("&");
for(var i = 0;i < aData.length;i++){
var sName = aData[i].substring(0,aData[i].indexOf("="));
var sValue = aData[i].substring(aData[i].indexOf("=")+1,aData[i].length);
alert(sName + ' = "' + unescape(sValue));
}
}
After a form is submitted, the form data is appended to the URL. For instance, after the file extension of the CGI script specified by the ACTION, the form data might have the following appearance:
?oFirstName=Gertrude&oLastName=Spencer&oPhrase=My%20favorite%20color%20is%20plaid.
The first character is a "?" and specifies that information following it is form data. Each name/value pair is grouped with the form control name, an equal sign ("="), and the value. The value is encoded so spaces and special characters are converted to their ASCII equivalents. Each name/value pair is separated by an "&".
The steps to recover the form data from the URL are:
After the values are unencoded, a Web author can continue using the form data via script.
When a form is submitted using the post possible value, and the form data is appended to the HTTP header, the CGI script specified in the ACTION generally provides a means to recover the name/value pairs. It is important to keep in mind that the submitted form information is available via client-side script when using the possible value get, but not when using post.
Submitting forms sometimes requires some insight and the ability to adapt to new technology. Similarly, as the document object model in Internet Explorer grows and objects are interwoven with one another, it is not always easy or clear how information can be submitted from these other objects. One of the best solutions for these cases happens to be one of the simplest and oldest: using an existing form control.
For example, the shining stars of new technology available as of Internet Explorer 5 are DHTML behaviors. While behaviors provide a robust information-access solution to Web authors, they are not inherently submitted with the FORM element unless they are part of a form control. It is unnecessary, though, that a behavior should be submitted with other controls simply because the methodology exists to handle this case. Information supplied by the behavior can easily be transferred into the VALUE attribute of an INPUT_hidden control, or any other control that submits the VALUE attribut. If a Web author wants to send information gathered from the CLIENTCAPS behavior, that information can be moved to a form control for the submission process.
The following code outlines how information gathered from a DHTML behavior can be submitted using a form control.
Start with a TEXTAREA control, an object participating in the CLIENTCAPS behavior, and a button to copy the data.
<TEXTAREA ID = "oOutput" COLS = "50" ROWS = "10"> </TEXTAREA> <DIV ID = "oClientCaps" STYLE = "url(#default#clientCaps)"> </DIV> <INPUT TYPE = "button" VALUE = "Copy Data" onclick = "fnGetCaps()">
Next, prepare the information in a format that can be accessed and used on the server, or the target of the form submission. For this sample, the information is stored in a comma-delimited list.
<SCRIPT>
function fnGetCaps(){
try{
oClientCaps.style.behavior = "url(#default#clientCaps)";
var sClientData="";
for(var i=0;i<pClientCaps.length;i++){
sClientData+="|" + pClientCaps[i]
+ "|,|" + eval("oClientCaps."
+ pClientCaps[i]) + "|\n";
}
oOutput.value=sClientData;
}
catch(e){
alert("Exception Error:\n\n" + e.error);
}
}
</SCRIPT>
With the growing popularity of DHTML, there are times when form controls are not needed but information needs to be submitted. The INPUT_hidden control is an ideal solution. The name/value pair is submitted, but the control itself is not rendered. Web authors can also take advantage of CSS and DHTML to enhance form controls so they are better integrated with other designs on a particular page.
Related Articles
Intelliforms Overview
Does this content meet your programming needs? Write us!
© 1998 Microsoft Corporation. All rights reserved. Terms of use.
Back to top