This chapter is from the book
This chapter is from the book
This chapter is from the book
HTML Forms
Web pages often contain fields where you can enter information. Examples include select boxes, check boxes, and fields where you can type information. Table 3.2 lists some popular HTML form tags.
Table 3.2. Some Common HTML Form Tags
|
Tag |
Description |
|
<form>...</form> |
Container for the entire form |
|
<input /> |
Data entry element; includes text, password, check box and radio button fields, and submit and reset buttons |
|
<select>...</select> |
Drop-down select box |
|
<option>...</option> |
Selectable option within select box |
|
<textarea>...</textarea> |
Text entry field with multiple rows |
After you have completed the form you are usually invited to submit it, using an appropriately labeled button or other page element.
At this point, the HTML form constructs and sends an HTTP request from the user-entered data. The form can use either the GET or POST request type, as specified in the method attribute of the <form> tag.
GET and POST Requests
Occasionally you may hear it said that the difference between GET and POST requests is that GET requests are just for GETting (that is, retrieving) data, whereas POST requests can have many uses, such as uploading data, sending mail, and so on.
Although there may be some merit in this rule of thumb, it's instructive to consider the differences between these two HTTP requests in terms of how they are constructed.
A GET request encodes the message it sends into a query string, which is appended to the URL of the server resource. A POST request, on the other hand, sends its message in the message body of the request. What actually happens at this point is that the entered data is encoded and sent, via an HTTP request, to the URL declared in the action attribute of the form, where the submitted data will be processed in some way.
Whether the HTTP request is of type GET or POST and the URL to which the form is sent are both determined in the HTML markup of the form. Let's look at the HTML code of a typical form:
<form action="http://www.sometargetdomain.com/somepage.htm" method="post"> Your Surname: <input type="text" size="50" name="surname" /> <br /> <input type="submit" value="Send" /> </form>
This snippet of code, when embedded in a web page, produces the simple form shown in Figure 3.1.
)
Figure 3.1 A simple HTML form.
Let's take a look at the code, line by line. First, we begin the form by using the <form> tag, and in this example we give the tag two attributes. The action attribute determines the URL to which the submitted form will be sent. This may be to another page on the same server and described by a relative path, or to a remote domain, as in the code behind the form in Figure 3.1.
Next we find the attribute method, which determines whether we want the data to be submitted with a GET or a POST request.
Now suppose that we completed the form by entering the value Ballard into the surname field. On submitting the form by clicking the Send button, we are taken to http://www.sometargetdomain.com/somepage.htm, where the submitted data will be processed—perhaps adding the surname to a database, for example.
The variable surname (the name attribute given to the Your Surname input field) and its value (the data we entered in that field) will also have been sent to this destination page, encoded into the body of the POST request and invisible to users.
Now suppose that the first line of the form code reads as follows:
<form action="http://www.sometargetdomain.com/somepage.htm" method="get">
On using the form, we would still be taken to the same destination, and the same variable and its value would also be transmitted. This time, however, the form would construct and send a GET request containing the data from the form. Looking at the address bar of the browser, after successfully submitting the form, we would find that it now contains:
http://www.example.com/page.htm?surname=Ballard
Here we can see how the parameter and its value have been appended to the URL. If the form had contained further input fields, the values entered in those fields would also have been appended to the URL as parameter=value pairs, with each pair separated by an & character. Here's an example in which we assume that the form has a further text input field called firstname:
http://www.example.com/page.htm?surname=Ballard&firstname=Phil
Some characters, such as spaces and various punctuation marks, are not allowed to be transmitted in their original form. The HTML form encodes these characters into a form that can be transmitted correctly. An equivalent process decodes these values at the receiving page before processing them, thus making the encoding/decoding operation essentially invisible to the user. We can, however, see what this encoding looks like by making a GET request and examining the URL constructed in doing so.
Suppose that instead of the surname field in our form we have a fullname field that asks for the full name of the user and encodes that information into a GET request. Then, after submitting the form, we might see the following URL in the browser:
http://www.example.com/page.htm?fullname=Phil+Ballard
Here the space in the name has been replaced by the + character; the decoding process at the receiving end removes this character and replaces the space.
The XMLHTTPRequest object at the heart of all Ajax applications uses HTTP to make requests of the server and receive responses. The content of these HTTP requests are essentially identical to those generated when an HTML form is submitted.