Reading Input from Other Form Elements

A PHP program can read the input from any type of HTML form element. In all cases, the name attribute of the HTML form object becomes a variable name in PHP. In general, the value of the PHP variable comes from the value property of the form object.

Introducing the borderMaker program

To examine most of the various form elements, I built a simple page to demonstrate various attributes of Cascading Style Sheet borders. The HTML program is shown in Figure 2.13.

Figure 2.13: The borderMaker HTML page uses a text area, two list boxes, and a select group.

Building the borderMaker.html Page

The borderMaker.html page contains a very typical form with most of the major input elements in it. The code for this form is

<html>
<head>
<title>Font Choices</title>
</head>
<body>
<center>
<h1>Font Choices</h1>
<h3>Demonstrates how to read HTML form elements</h3>

<form method = "post"
      action = "borderMaker.php">


<h3>Text to modify</h3>
<textarea name = "basicText"
          rows = "10"
          cols = "40">
Four score and seven years ago our fathers brought forth on this
continent a new nation, conceived in liberty and dedicated to the
proposition that all men are created equal. Now we are engaged in a
great civil war, testing whether that nation or any nation so
conceived and so dedicated can long endure.
</textarea>

<table border = 2>
<tr>
  <td><h3>Border style</h3></td>
  <td colspan = 2><h3>Border Size</h3></td>
</tr>

<tr>
<td>
<select name = borderStyle>
  <option value = "ridge">ridge</option>
  <option value = "groove">groove</option>
  <option value = "double">double</option>
  <option value = "inset">inset</option>
  <option value = "outset">outset</option>
</select>
</td>
<td>

<select size = 5
        name = borderSize>
  <option value = "1">1</option>
  <option value = "2">2</option>
  <option value = "3">3</option>
  <option value = "5">5</option>
  <option value = "10">10</option>
</select>
</td>

<td>
<input type = "radio"
       name = "sizeType"
       value = "px">pixels<br>
<input type = "radio"
       name = "sizeType"
       value = "pt">points<br>
<input type = "radio"
       name = "sizeType"
       value = "cm">centimeters<br>
<input type = "radio"
       name = "sizeType"
       value = "in">inches<br>
</td>
</tr>
</table>

<input type = "submit"
       value = "show me">

</form>

</center>
</body>
</html>

The borderMaker.html page is designed to interact with a PHP program called borderMaker.php, as you can see by inspection of the action attribute. Note that I added a value attribute for each option element, and the radio buttons all have the same name but different values. The value attribute becomes very important when your program is destined to be read by a program, as you shall see very shortly. Finally, the Submit button is critical, because nothing interesting will happen until the user submits the form.

TRICK?

You might have noticed I didn't include checkboxes in this particular example. Checkboxes work much like the other form elements, but in practice they are more useful when you understand conditional statements, which will be the major topic of the next chapter. You'll get plenty of opportunity to practice these elements when we get there.

Reading the Form Elements

The borderMaker.php program expects input from borderMaker.html. When the user submits the HTML form, the PHP program produces results like those shown in Figure 2.14.

Figure 2.14: The borderMaker.php code reacts to all the various input elements on the form.

In general, it doesn't matter what type of element is used on an HTML form. The PHP interpreter simply looks at the name of each element and the value. By the time the information gets to the server, it doesn't really matter what type of input element was used. PHP automatically creates a variable corresponding to each form element. The value of that variable will be the value of the element. The code used in borderMaker.php illustrates:

<html>
<head>
<title>Your Output</title>
</head>
<body>
<h1>Your Output</h1>
<center>
<?
$theStyle = <<<HERE
"border-width:$borderSize$sizeType;
border-style:$borderStyle;
border-color:green"
HERE;

print "<div style = $theStyle>";
print $basicText;
print "</span>";

?>
</center>

</body>
</html>

In the case of text boxes and text areas, the user types the value directly in. In borderMaker.html, there is a text area called basicText. The PHP interpreter creates a variable called $basicText. Anything typed into that text box (as a default the first few lines of the Gettysburg Address) becomes the value of the $basicText variable.

Reading Select Elements

Recall that both drop-down lists and list boxes are created with the select object. That object has a name attribute. Each of the possible choices in the list box is an option object. Each option object has a value attribute.

The name of the select object will become the name of the variable. For example, borderMaker.html has two select objects, borderSize and borderStyle. The PHP program can expect to find two corresponding variables, $borderSize and $borderStyle. Because there is no place for the user to type a value into a select object, the values it can return must be encoded into the structure of the form itself. The value of whichever option the user selected will be sent to the PHP program as the value of the corresponding variable. For example, if the user chose groove as the border style, the $borderStyle variable will have the value groove in it.

IN THE REAL WORLD

Note that the value of the options doesn't necessarily have to be what the user sees on the form. This is handy if you want to show the user one thing, but send something else to the server. For example, you might want to let the user choose from several colors. In this case you might want to create a list box that shows the user several color names, but the value property corresponding to each of the option objects might have the actual hexidecimal values used to generate the color. Similar tricks are used in online shopping environments where you might let the user choose an item by its name, but the value associated with that item might be its catalog number, which is easier to work with in a database environment.

TRAP?

You might recall that it is possible to have multiple selections enabled in a list box. In that case, the variable will contain a listof responses. While managing this list is not difficult, it is a topic for another chapter (To be specific, Chapter 4, "Loops and Arrays." For now, concentrate on the singular style of list box.

Reading Radio Groups

CSS allows the developer to indicate sizes with a variety of measurements. This is an ideal place for a group of radio buttons because only one unit of measure is appropriate at a time. Even though there are four different radio buttons on the borderDemo.html page with the name sizeType, the PHP program will only see one $sizeType variable. The value associated with whichever option is selected will become the value of the $sizeType variable. Note that like option elements, it is possible for the value of a radio button to be different than the text displayed beside it.

IN THE REAL WORLD

How do you decide what type of form element to use?

You might wonder if all these different form elements are necessary, since they all boil down to a name and value by the time they get to the PHP interpreter. The various kinds of user interface elements do make a difference in a few ways:

First, it's easier (for many users) to use a mouse than to type. Whenever possible, it is nice to add lists, checks, and options so the user can navigate your forms more quickly. Typing is often much slower than the kinds of input afforded by the other elements.
Secondly, interface elements (especially the drop-down list box) are extremely efficient in terms of screen space. You can pack a lot of choices on a small screen by using drop-downs effectively. While you might not think this is an issue any more, take a look at how many people are now surfing the Web with PDAs and cell phones.
Third, your life as a programmer is much easier if you can predict what the user will be sending you. When users type things, they make spelling and grammar mistakes, use odd abbreviations, and are just unpredictable. If you limit the user's choices whenever possible, you are less likely to frustrate your users because your program should be able to anticipate all the possible choices.