A Script to Acquire User Input

For now, we'll keep our HTML separate from our PHP code. Listing 10.2 builds a simple HTML form.

Listing 10.2 A Simple HTML Form

 1: <!DOCTYPE html PUBLIC
 2:     "-//W3C//DTD XHTML 1.0 Strict//EN"
 3:     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 4: <html>
 5: <head>
 6: <title>Listing 10.2 A Simple HTML Form</title>
 7: </head>
 8: <body>
 9: <div>
10: <form action="listing10.3.php" method="get">
11: <p><input type="text" name="user"/></p>
12: <p>
13: <textarea name="address" rows="5" cols="40">
14: </textarea>
15: </p>
16: <p><input type="submit" value="hit it!" /></p>
17: </form>
18: </div>
19: </body>
20: </html>>

We define a form that contains a text field with the name "user" on line 11, a text area with the name "address" on line 13, and a submit button on line 16. It is beyond the remit of this book to cover HTML in detail. If you find the HTML in these examples hard going, take a look at Sams Teach Yourself HTML in 24 Hours or one of the numerous online HTML tutorials. The form element's action argument points to a file called listing10.3.php, which processes the form information. Because we haven't added anything more than a filename to the action argument, the file listing10.3.php should be in the same directory on the server as the document that contains our HTML.

Listing 10.3 creates the code that receives our users' input.

Listing 10.3 Reading Input from the Form in Listing 10.2

 1: <!DOCTYPE html PUBLIC
 2:     "-//W3C//DTD XHTML 1.0 Strict//EN"
 3:     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
 4: <html>
 5: <head>
 6: <title>Listing 10.3 Reading Input from the Form in Listing 10.2</title>
 7: </head>
 8: <body>
 9: <div>
10: <?php
11: print "Welcome <b>".$_GET['user']."</b><br/>\n\n";
12: print "Your address is: <br/><b>".$_GET['address']."</b>";
13: ?>
14: </div>
15: </body>
16: </html>

This script is the first script in this book that is not designed to be called by hitting a link or typing directly into the browser's location field. We include the code from Listing 10.3 in a file called listing10.3.php. This file is called when a user submits the form defined in Listing 10.2.

In the code, we have accessed two elements of the superglobal $_GET array, user and address. It should come as no surprise that these variables contain the values that the user added to the text field named "user" and the text area named "address". We use the $_GET array because the form uses the HTTP get method to submit its data. Had we used the HTTP post method, we would have accessed elements of the $_POST array:

<form action="listing10.3.php" method="post">

We do not have to know or test the submission method used, however. PHP provides us with the $_REQUEST array. It will contain the merged contents of $_POST, $_GET, and $_COOKIE. We could therefore rewrite the code to output our elements in Listing 10.3 so that the script would work with both post and get methods.

print "Welcome <b>".$_REQUEST['user']."</b><br/>\n\n";
print "Your address is: <br/><b>".$_REQUEST['address']."</b>"; mmnmnnnn ,, nn l ln ,

The register_globals php.ini Directive Is Disabled

Versions of PHP prior to 4.2 shipped with the php.ini register_globals directive set to 'Yes' by default. This caused submitted parameters ('user' and 'address' in Listing 10.2) to be generated as global variables ($user, $address). This functionality is now disabled by default, and register_globals is set to 'No'. You can reverse this setting yourself by setting register_globals back to 'Yes' in the php.ini file, but use of automatic globals is now actively discouraged because of the potential security risks involved.
The superglobal variables $_GET, $_SET, and $_REQUEST are unaffected by the register_globals directive.

[ Team LiB ]