WebCom Home Page
WebCom
WEBCOM FORMS GUIDE

INFORMATION ON CREATING YOUR OWN HTML FILL IN FORMS.
WebCom
Resources


HTML Forms
   · Introduction
   · Forms Tutorial
   · Forms Processor

Resources

Control Panel Login

Customer Support

Contact Us

About WebCom

 


Forms Tutorial

Constructing a form is far less intimidating that it may appear at first. If you've already set up web pages using HTML, then you'll move naturally into setting up forms, which are also written using HTML tags embedded right in an ordinary HTML page.

As with all other HTML, the appearance of a form can be dramatically altered by the browser used to view it. A great way to learn Forms, as with other HTML, is to examine the work of others: feel free to look at the source of these tutorials, or that of any other forms you are impressed by. Use the "Document Source" option in your graphical browser, or the "\" key in lynx to do this.



Example form

Enter your name:

Here's the source HTML for the above form:

< FORM METHOD=POST
ACTION="http://www.webcom.com/cgi-bin/form" >

Enter your name:
< INPUT NAME=your_name >
< INPUT TYPE=submit VALUE="Test this form" >
< /FORM >

Let's take a close look at each of the elements of this form.


The FORM tag - Opening and Closing a Form
<FORM METHOD=POST ACTION="[name of program]">
</FORM>

These tags start and end a form (all input fields of the form are placed between these two tags). METHOD specifies which technical protocol the web server will use to pass the form data to the program which processes it (always set it to POST), and ACTION tells the server exactly which program that is. Note: POST must be capitalized, otherwise the method defaults to "GET".

In our example, the action is a program is the WebCom Forms Processor. In this case we configured it just say hello and echo the name you entered. Most or all of your forms in your WebCom account will point to http://www.webcom.com/cgi-bin/form - the WebCom form processor, a program which reads a configuration file you set up in your directory in which you define how you want the form data to be formatted and routed, what to display to the user after they submit the form, etc. (the configuration file is optional - if you don't have one the form processor simply emails the contents of the form to you (the name and value of each field on the form when the user submitted it)).

A web page (i.e., an HTML document) may include multiple forms; however, forms may not be nested (you cannot create a form within a form). You must end the current form with < /FORM > before you can start a new form.


Getting a line of text from the user
Enter your name: <INPUT NAME=your_name>

The above code creates the text input box for the user's name in our example form. Most form fields begin with < INPUT NAME=[field_name] and end with > . NAME defines the name of the data for the field; it's how the program which processes the form references the data from this field.

You can pick any name for your fields, just make sure it is not one of the pre-defined Forms parameters. These variables, when set to have values, perform certain specialized tasks. For instance, one of the most common errors in creating forms is to have an input field ask for a client's email address, and using the variable email to store the address in. The word 'email', however, is one of the predefined parameters. Giving email a value tells the Forms Processor to send the form's results to that address, which is usually not what is intended.

You also want to be careful to use only letters, numbers, and underscores in your field names. The HTML standard allows other symbols other than letters, numbers, and underscores to be used in a field name but the WebCom form processor will not recognize such field names (and it's good practice to stick with letters, numbers and underscores for readability). TYPE defines the various types of input fields recognized in the current HTML sepecification (text, radio, checkbox, password, or submit), which we'll look at a little later.

The text input type creates what user interface designers call a single line edit, an input field which allows the user to enter and/or edit a single line of text. This is the type of field we used in our sample form. We did not have to say TYPE=text because that is the default type, but we could just as well have coded the field as follows with the same result:

Enter your name: <INPUT TYPE=text NAME=your_name>

Some other things we can do with a text input field are define an initial value for the field, and make it longer (or shorter):

Enter your name:
<INPUT TYPE=text NAME=your_name SIZE=50 VALUE="Joe Schmoe" >

Enter your name:
Note that the user could still type more than 50 characters in the above field, the browser just scrolls the text in the window. You can also limit the length of the text input by the user by including a MAXLENGTH=nn in the INPUT field definition.

Enter your name:
<INPUT TYPE=text NAME=your_name SIZE=50 VALUE="Joe Schmoe" MAXLENGTH=50>

The Submit Button
<INPUT TYPE=submit VALUE="Test this form">

Each form must have exactly one field of type submit. This creates the button the user pushes when they're done filling out a form, and should come after all the other input fields. If a form doesn't have a submit button, it is useless since once the user finishes typing in the data they won't have anyway of sending it to a server. You can put whatever words you like on the submit button, using the VALUE keyword. If you omit the VALUE keyword, the button will be labeled "Submit".

When the user clicks the submit button, the browser collects the values of each of the input fields (text typed by the user, etc.) and sends them to the web server identified in the ACTION keyword of the FORM open tag (and that web server passes that data to the program identified in the ACTION, using the METHOD specified).

You may at some point get the urge to create a form with two or more submit buttons, each of which you'd like to perform a different task (say one to subscribe to a mailing list, and another to unsubscribe. This is a natural inclination, but unfortunately you can't do it with the current WWW standards. Sometimes you can simulate this behavior by having multiple forms on one page, each with its own submit button (and perhaps nothing else). But if you associate multiple submit buttons with the same input fields by putting them on the same form (that is, between the same FORM tags), all the submit buttons will do exactly the same thing (namely pass the data of that form to the program identified by the ACTION identifier).

Next lesson: TEXTAREA - multi-line text fields

Index of tutorial topics



WebCom Home
Contact us by email:info@webcom.com
phone: 1-888-8WEBCOM (1-888-893-2266)
Copyright © 1994 - 2001 Web Communications.   A Member of the Verio Group.