Slippery Rock University | Dr. Deborah Whitfield | Go Browns! |
<form> | action | method | name |
<input> | type | value | name |
text box | submit button | radio buttons | checkboxes |
<textarea> | rows | cols | name |
<select> | <option> | <label> | get & post |
Writing web apps is beyond the scope of the book, We will use a couple of apps the authors provide for this chapter.
http://www.headfirstlabs.com/constest.php
http://www.starbuzzcoffee.com/processorder.php
That means the examples will be somewhat closer to the text than usual.
Later we will use JavaScript to add more (local) interaction to our forms. If you want a better idea of how names and values work, change the action to a generic form processing app that simply tells you what the values it received are. Form2 (below) has this in the file as a comment, but you can change the action for any of the forms as shown:
<form action="http://cs.sru.edu/~whit/cpsc130/php/process.php" method="POST">
Form elements require a unique name (within a page) so we can tell the various fields apart. But, they are also used to send values to the web app that processes them. The web app has to use the very same names that your form does. If the form is expecting your user Id, password and the name of a DVD you want to rent, it might use the names userID, password and dvd. When you create a form to collect and send this data, you must also use the names userID, password and dvd.
Computers are actually fairly stupid. If we could choose any name for our forms, the web app would have no real way of distinguishing them. I suppose we could try to handle every possible name someone might pick for the DVD (dvd, DVD, movie, title, movieTitle, film, ...), but we could never get them all. So, the simple approach is used instead – your name must agree with the web apps name exactly.
I don't have anything against CSS and styles, except that we haven't covered it and it has a completely different syntax than HTML. (So does JavaScript – three in one semester seems a bit cruel.) Even the authors note that using CSS for tables is a bit controversial because tables tend to provide nice organization.
Some of the tables here and in the JavaScript book use a bit of CSS. You should be able to simply copy it without worrying about it. Just remember that you don't need it. (Your favorite PJs may not be stylish, but they get the job done.)
form1 | Text input fields |
form2 | The author's contest submission form. This uses text fields and actually submits the data to a real web application. (Wow!) I included part of the web app code to show you how the names in the form matches the name in the web app. That is very important. |
form3 | This is exactly the same as form2, except the label of the submit button is changed using the value attribute. |
form4 | Two sets of radio buttons. Again, note the additional formatting. |
form5 | Two sets of checkboxes. Since you can get none, all or any combination of these, two sets would only be used for logical grouping. |
form6 | More radio buttons, but this time with an error in the naming causing two groups to actually be one. |
form7 | A text box (textarea) for user input. |
form8 | Two drop-down lists (using select and option). Each provides one value. |
form9 | The author's Starbuzz Coffee page, including the Bean Machine form. |
form9a | This version of the authors' coffee page uses JavaScript to display the values (though it doesn't work in all browsers). This is only here as a preview of what's to come. |
form10 | The authors' coffee form that uses another actual web application. Response varies depending on what fields are filled in. This time I used the GET method so you can see the parameters sent to the app in the URL. |
We will return to forms after learning a bit about JavaScript. This will allow us to work with the data in the browser itself, for example, making sure required data is provided. You may wish to return to this chapter as we read the next book.
One thing that may help is a way to see what is being POSTed when the form is submitted. I modified form10 to send it's output to a generic script that simply reports what information it receives. You can use this script with any form you are developing. So the only change in form11 is in the form tag:
<form action="http://cs.sru.edu/~whit/cpsc130/php/process.php" method="POST">