HTML Forms: Interacting with the Net
You have set up a World Wide Web server, and now have a number of HTML (hypertext markup language) documents for web-surfing visitors to enjoy. You're comfortable with HTML, and are ready to find new things for your server to do. In your network travels, you remember filling out some electronic forms to give feedback to the creator of one of your favorite home pages.
This article will help you acquire the basic knowledge needed to write HTML forms, and explains what needs to be done so that you and your server can interact with your Web visitors.
A working form really consists of three basic elements. The first is the form itself. The form is constructed using HTML text, as for your homepage, with a few different markup tags. The second element is the script or program. This program must be constructed in accordance with the common gateway interface (CGI) specification, if it is to communicate properly with your server and the user's Web client. The CGI script is the engine behind the interface; it will actually act on the data the user types into the form. The third element is the httpd (hypertext transfer protocol daemon) server, which calls the CGI program, passing it the data the user has entered.
Let's take a look at what elements a form can posses. Much like other HTML constructs, forms are built using markup tags and simple text. A form is encapsulated by <FORM>...</FORM>, where the ... is replaced by text and other form markups. Keep in mind that markup tags are case insensitive, though I will continue to capitalize them for clarity. Following is a list and descriptions of the major available form markup tags.
Indicates the start and end of an HTML form.
Indicates the start and end of form input.
Indicates the start and end of a selection list.
Indicates the start and end of a free-form text input area.
Form markup tags may use attributes to help control how a form will be displayed to the user. Let's take each markup tag in turn, and examine the valid attributes for each. First let's look at the FORM tag.
Typically a URL indicating a script or program to be executed.
Valid values are POST and GET.
The ACTION attribute specifies a URL (uniform resource locator) which will be used to carry out some action based on what is entered in the form. The URL usually specifies a program, which exists in a script directory on the server. For instance, http://some.server/cgi-bin/donothing.sh will result in the form data being returned to the program donothing.sh for processing. The program will then return an appropriate response to the client.
The METHOD attribute is used to specify how the data which is entered into the form is to be returned to the server. The data may be appended to the URL specified by the action attribute using the GET method. When the GET method is used, the http server will pass the information to the ACTION program encoded in an environment variable. When the POST method is used, the http server will pass the information to standard input.
<FORM ACTION="http://www.you.org/cgi-bin/donothing.sh" METHOD=POST>
begins the definition of a form which is processed by the donothing.sh script on the current host, which reads data from its standard input.
The INPUT tags are used to specify fields where data can be entered by the user. This tag, like all of the remaining form markup tags, must appear between a <FORM> tag and its associated </FORM> tag. Following is a list of valid attributes.
Indicates a symbolic name for the input field. The ACTION program uses this to differentiate fields.
Specifies the type, such as checkbox or radio button, that is to be used.
This gives a default value for the input field.
A boolean indication of status for elements such as checkboxes.
The physical display size of text entry fields.
The maximum allowable number of input characters for text entry fields.
The NAME of an INPUT field allows fields to be differentiated or grouped. The name of a field is used by the ACTION program to determine what a user entered in each field of the form. The NAME attribute is also used to establish logical groupings of some form element types, specifically radio buttons.
Valid settings for the TYPE attribute are checkbox, text, password, radio, hidden, reset and submit. A checkbox is an element which can take on one of two states, either checked or not checked. This provides a basic boolean true or false element for form entry. The text element provides a single-line text entry field in which the user can enter data. A password field is a text entry field in which the entered text is hidden from view in some fashion.
Radio buttons are groups of buttons which allow a single button to be toggled at a time. The other buttons in the group are untoggled when one button of the group is selected. A radio button group is established by setting the NAME attribute for each button in the group to the same value.
A hidden input is not displayed to the user at all, and the user cannot modify it. A hidden input encodes state information into the form. For instance, it might be possible to have one form which should be processed in different ways, depending on context. Each instance of the form could include hidden input indicating the context and directing the processing appropriately.
Of particular note are the submit and reset input types. Clicking on submit causes the form contents to be transmitted to the server, and then to the ACTION program for processing. The reset button causes the form elements to be set to their initial values, allowing the user to easily return the form to its initial state.
A default value for a form element can be specified using the VALUE attribute. For text entry elements, this indicates a default string of characters that are initially present when the form is retrieved. If the field is a radio button, this is the value the element takes on when it is checked (when the element isn't checked, it has no value). For the submit and reset elements, the VALUE attribute can be used to set the button label.
The CHECKED attribute is valid only for the checkbox and radio elements. If the CHECKED attribute is present, the radio button or checkbox is toggled by default. Setting the physical length of a text entry field can be done by using the SIZE attribute.
The MAXLENGTH attribute limits the number of characters that are accepted in a particular text entry field.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- I once had a better way I
3 hours 23 min ago
- Not only you I too assumed
3 hours 41 min ago
- another very interesting
5 hours 34 min ago
- Reply to comment | Linux Journal
7 hours 27 min ago
- Reply to comment | Linux Journal
14 hours 21 min ago
- Reply to comment | Linux Journal
14 hours 38 min ago
- Favorite (and easily brute-forced) pw's
16 hours 29 min ago
- Have you tried Boxen? It's a
22 hours 21 min ago
- seo services in india
1 day 2 hours ago
- For KDE install kio-mtp
1 day 2 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?