Components of a Form

Components of a Form


	Forms are among the most useful components of HTML, and are what make web pages interactive. Forms provide a way to accept data from the user and pass it to an application through what is called CGI (Common Gateway Interface). Forms do not provide any sort of data validation -- that is left to the CGI application or JavaScript enhancements. The htmlForm class is used to construct forms in documents. The htmlCgi class is used to process form data as part of a CGI application.

	Forms consist of the following components:

action application (which acts upon the submitted data)

optional encoding type

data input elements (i.e., text boxes, checkboxes, buttons, etc.)

data display elements (i.e., descriptive text, labels, and images)

submit method (GET or POST)

submit button (for invoking the action)


	A page can have multiple forms, but each form must be independent of the others. Forms cannot be nested.

	The htmlForm class, derived from htmlGroup, manages forms within the html++ framework. Text, images, and user-input elements are added to htmlForm objects using the << insertion operator or the Add() method. Once the form is constructed, it is output to a page or other html++ object using the << insertion operator or Add() method as well.

Form Action

Every form is associated with an action URL that will receive and process data from the form. Such action URL's can be any CGI script or html++ application. Most web servers store such applications in a special directory called "/cgi-bin", which is an abbreviation for "CGI binaries", though your particular web server may differ. The action URL for an htmlForm object can be specified in the constructor, or via the Action() method.

Encoding Type

Browsers encode form data before passing it to the server. It is up to the server to either decode the information (the field names and values) or pass it, still encoded, directly to the application. The standard encoding format for form data is "application/x-www-form-urlencoded". This standard converts spaces to "+" symbols, non-printable characters into "%xx" hex codes, and separates values with "&" characters. This type of encoding is the reason URL's sometimes seem rather lengthy or otherwise unusual.

Another type of encoding exists, called "multipart/form-data", and is required when using file upload elements (see htmlInputFile). Netscape supports this encoding type, as does Microsoft Internet Explorer version 4 (version 3 can support it as well but requires a patch).

For convenience, htmlForm automatically sets the proper encoding type whenever an htmlInputFile object is added directly to an htmlForm object. If however, your application adds htmlInputFile objects to an intermediate object (such as htmlContainer or htmlFont), you must manually specify "multipart/form-data" encoding using the Encode() method.

Input and Display Elements

Forms can contain any html++ object except another htmlForm object. You can add and combine whatever text and images are appropriate to your application. html++ objects representing user input fields are all named as htmlInputXXX (e.g., htmlInputText, htmlInputCheckBox, htmlInputHidden, htmlInputPassword, etc.).

It's often useful to align labels and fields using tables (see htmlTable).

Submit Method

The submit method controls how the browser sends form data to the server. There are two ways: GET and POST. The type of submit method can be specified in the htmlForm constructor (the default is POST) or via the Method() method.

The POST method sends form data to the server in two steps: 1) the browser contacts the server using the action URL, and 2) once contact has been established the data is sent as a separate transmission.

The GET method sends form data to the server in a single step by encoding and appending form name/value pairs to the action URL (with a "?" separator).

When processing form data using the htmlCgi class, you do not need to be concerned with which submit method is used. htmlCgi automatically recognizes and decodes both, providing a uniform interface to name/value form data.

TIP: The htmlCgi class provides three routines, Encode(), AsURL(), and AsHidden(), that are useful for converting and encoding lists of CGI name/value pairs as URL's or as hidden fields in a form.

Here are a few suggestions for choosing which type of submit method to use in your own forms:

If maximum performance is a goal, use the GET method.
If a large number of name/value pairs are being sent, use the POST method as some servers limit URL length.
If security is an issue, avoid the GET method which allows users to see form data in the action URL.

Submit Button

Every form must contain a "submit" button, which the user presses to invoke the action of the form, sending the entered data to the server. There may be more than one submit button on a form.

©1998 DC Micro Development. All rights reserved.
No portion of this document may be c opied or reproduced without expressed written consent.
html++ is a trademark of DC Micro Development.

	Every form is associated with an action URL that will receive and process data from the form. Such action URL's can be any CGI script or html++ application. Most web servers store such applications in a special directory called "/cgi-bin", which is an abbreviation for "CGI binaries", though your particular web server may differ. The action URL for an htmlForm object can be specified in the constructor, or via the Action() method.

	Browsers encode form data before passing it to the server. It is up to the server to either decode the information (the field names and values) or pass it, still encoded, directly to the application. The standard encoding format for form data is "application/x-www-form-urlencoded". This standard converts spaces to "+" symbols, non-printable characters into "%xx" hex codes, and separates values with "&" characters. This type of encoding is the reason URL's sometimes seem rather lengthy or otherwise unusual.

	Another type of encoding exists, called "multipart/form-data", and is required when using file upload elements (see htmlInputFile). Netscape supports this encoding type, as does Microsoft Internet Explorer version 4 (version 3 can support it as well but requires a patch).

	For convenience, htmlForm automatically sets the proper encoding type whenever an htmlInputFile object is added directly to an htmlForm object. If however, your application adds htmlInputFile objects to an intermediate object (such as htmlContainer or htmlFont), you must manually specify "multipart/form-data" encoding using the Encode() method.

	Forms can contain any html++ object except another htmlForm object. You can add and combine whatever text and images are appropriate to your application. html++ objects representing user input fields are all named as htmlInputXXX (e.g., htmlInputText, htmlInputCheckBox, htmlInputHidden, htmlInputPassword, etc.).

	It's often useful to align labels and fields using tables (see htmlTable).

	The submit method controls how the browser sends form data to the server. There are two ways: GET and POST. The type of submit method can be specified in the htmlForm constructor (the default is POST) or via the Method() method.

	The POST method sends form data to the server in two steps: 1) the browser contacts the server using the action URL, and 2) once contact has been established the data is sent as a separate transmission.

	The GET method sends form data to the server in a single step by encoding and appending form name/value pairs to the action URL (with a "?" separator).

	When processing form data using the htmlCgi class, you do not need to be concerned with which submit method is used. htmlCgi automatically recognizes and decodes both, providing a uniform interface to name/value form data.

	TIP: The htmlCgi class provides three routines, Encode(), AsURL(), and AsHidden(), that are useful for converting and encoding lists of CGI name/value pairs as URL's or as hidden fields in a form.

	Here are a few suggestions for choosing which type of submit method to use in your own forms:

	Every form must contain a "submit" button, which the user presses to invoke the action of the form, sending the entered data to the server. There may be more than one submit button on a form.