Slippery Rock University Dr. Deborah Whitfield Go Browns!



CH14: xhtml forms: Getting Interactive


Boiled down:

<form> action method name
<input> type value name
text box submit button radio buttons checkboxes
<textarea> rows cols name
<select> <option> <label> get & post

Brief Notes:

Terms

<form>
Block structured element that often includes other block elements along with various input fields (textual & clickable). Some elements you might commonly find inside a <form> are: <p> and <table>
action
Attribute whose value is a URL (or relative pathname) for the web application that will receive the input and send back some kind of reply. We will be using some web apps deveoloped by the authors. Although forms are always supposed to have an action, we will somethimes leave it out when we are studying JavaScript to avoid the expected reply — a new web page to be displayed.
method
Another attribute. There are two methods for sending form data to the web app specified with the action attribute: get & post. GET sends all the data input appended to the URL, which means limited size and no secrecy. POST follows the process outlined below.
name
A unique identifier. Most forms and form elements will have a name, allowing us (and the web app) to refer to the values associated with them. Without a name, we won't be able to read (or set) the associated values. Some form elements require a name to work correctly.
<input>
We will use one of four types of input fields: submit button, text field, radio buttons, and check boxes. A button is a generic form of the submit button.
value
An attribute that provides an initial value (or a button label). Both act as a kind of prompt for the end user, the person browsing the page. We use the value attribute to remember/access user input or (by changing the value) to "say" something to the user.
sample text box type="text"
A one line text input box. The user types something in and we use the value, or we set the value to some text for the user.

sample submit button type="submit"
A button labelled submit (unless you provide a value) which causes the "load process" below to begin.

sample radio buttons type="radio"
A list of these provide options (through the various values) for clicking. Only one of the buttons with the same name may be checked at any time.

sample check boxes type="checkbox"
A list of these provide options (through the various values) for clicking. Zero or more of the buttons with the same name may be checked at any time. The resultant value is the (possibly empty) list of selected items.

sample text area <textarea>
Multiple lines of text input. You specify the size with rows and cols attributes. Basically a multi-line text box.

sample select with two options <select>
Provides a drop-down list of selectable options. Still need a name attribute. Contains multiple options — the options and the displayed content are often the same, perhaps using "CamelCase".
<option>
The value attribute gives the names of the items displayed.

Form Handling Process (for the POST method)

  1. Browser displays web page that includes a form and one or more controls.
  2. User enters data.
  3. User selects "submit" button
  4. Browser collects data names & values and send them to the server (URL specified as the value of action)
    1. The only difference for the get method is that the data names and values are simply appended to the web apps URL.
  5. Server hands data off to web app (URL)
  6. Web app constructs reply — a web page to display
  7. Server sends reply to browser
  8. Browser interprets and displays the (HTML) response

Web App

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">

A rose is a rose is a rose

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.

Stylish Forms

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.)

Examples

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.

Interactive Forms

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">

All work herein is subject to copyright. Original content to Dr. Paul Mullins, modifications by Dr. Deborah Whitfield, text content (Head First HTML with CSS & XHTML) to O'Reilly publishing, other tools ( such as HTML-Kit and FireFox) to their respective owners.