HTML Forms: Interacting with the Net
SELECT is the next major markup tag. The SELECT tag is used to encapsulate a selection list. Several <OPTION> tags may be included between a <SELECT> and a </SELECT>, to add elements to the list. A selection list may take on two physical forms. If it has a SIZE of one, it appears as a popup menu. If the SIZE attribute is greater than one, it appears as a scrollable list displaying SIZE options one at a time. Here are the possible attributes of the SELECT tag:
Indicates a symbolic name for the selection menu.
The physical number of lines that are visible at any time.
If this attribute is present, multiple items of the list may be selected at one time.
These attributes are straightforward, and I'll leave them for your exploration later. Before we move on, I should mention a little more about the <OPTION> tag. The option tag can have the attribute SELECTED. When present, this attribute indicates that a particular list item is selected by default. The <OPTION> tag is much like the <li> of normal HTML lists; it does not require a terminating </OPTION> tag. Instead, the appearance of an <OPTION> tag indicates the beginning of a new list item and the termination of any preceding items. Also, a selection list item can be only simple text. List items cannot be marked up, nor can they be anchored items.
A form element where a user can type in free-form text, much like entering text into an editor, is constructed using the TEXTAREA tag. A text entry area is has the basic form of:
The default text is the initial text, if any, which is present in the text entry area. This form element has three easy-to-use attributes.
Indicates a symbolic name for the selection menu.
The vertical size of the text entry area.
The horizontal size of the text entry area.
Now that we know what things we have available, let's create a basic form. Listing 1 shows a simple HTML form, while Figure 1(139K) displays how Mosaic might present this form.
Keep in mind that the ACTION attribute needs to specify your host and a valid script or program. In the example, the shell script echo.sh (shown later) will be executed on your.http.host when the form is submitted. The script or program needs to reside in a directory which your server recognizes as a valid location for executable programs. Be sure to check the documentation for your server to be sure it is configured properly to allow for this sort of execution. A typical location for these sorts of programs is in the cgi-bin directory under the server root, and that is how this example is configured.
The form is only one of the three parts necessary to interact with a user. The second is the http server, which we will not cover here (please refer to the documentation for your server). The third is a CGI program or script. As mentioned above, these programs must reside in a directory recognized by the http server as a valid location for executables. A CGI program needs to be able to understand the encoded form data as it is returned from a client, and must be able to respond appropriately. The encoded form data will appear either on the command line or in the environment variable QUERY_STRING, depending on whether a METHOD of GET or POST is used. Typically, a program needs only write the necessary response on stdout, and the response will then be transmitted back to the client by the http daemon.
A number of environment variables are also typically set by the server for the CGI program's use. Following is a partial list of environment variables that I find useful. Please refer to hoohoo.ncsa.uiuc.edu/cgi/env.html for further discussion of other environment variables.
Set to the METHOD used to make the request.
Set to the encoded form data when the GET METHOD is used.
Set to the remote hostname if available.
Set to the IP address of the remote host.
The length of the data returned in a client's query.
Usually, a CGI program need only respond to a request with an appropriate http header, possibly followed by a document. The response is simply written on stdout, where the data will be returned to the client. A header consists of an http header directive followed by a relevant text string. The header is terminated by a blank line. Two of the most used header directives are the Content-type and Location directives. The Content-type directive indicates the type of data which is to follow. For example, Content-type: text/html indicates that the document which follows the header on stdout is written in HTML. The Location directive is used to provide a means by which redirection can take place. For instance, Location: http://goto.another.host/web/doc.html would cause a client to retrieve the document specified in the URL.
Probably the easiest way to explore the construction of a CGI program is with an example. Listing 2 shows a shell script which will respond to a client's HTML form request.
The response is to echo the encoded query, some of the environment variables, and the decoded content of the query. This program is useful as a test program when creating new forms, and as a base for building other CGI scripts. Figure 2(135K) displays the results of posting the form shown in Figure 1 to this script.
Examine the QUERY_STRING in Figure 2 Notice that spaces are encoded as addition signs, and that an ampersand in the input is encoded as a hex value preceded by a percent sign. Also notice that each name/value pair is separated by an ampersand. The shell script decodes this string back into the data as it was entered by the user. There are other programs, such as CERN's cgiparse, which will also help you decode CGI form data.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development
- KDE Reveals Plasma Mobile