POST & GET with Forms

Web Applications

When we start to build pages in a server side scripting language, such as PHP, we can build web applications instead of pages. Instead of building a program in C++, we build a program using web pages as the interface for our user. One thing we can do is allow users to login and view 'member' data instead of 'public' data, such as their account information at a bank website. Behind the scenes, data such as the user's login and password are stored in a database managment system, such as MySQL.

Anatomy Of A Web Application

Fundamentally a web application is built of 3 parts:

1. Form
2. Formhandler
3. Feedback

Although not each of these parts are not always separate PHP files, it is common. Each of these are detailed below.

Forms As Primary Interface

The interface between a user and a web application is through a form. When you see a 'textbox' for entering info, such as a password, you are using a form as the interface to a web application. Form elements vary in their use and application. Watch the following 'movie' regarding the use and placement of form elements: Forms Reviewed

POST vs. GET

When you create a form, and hit submit, the information gets included with the request for the webpage you targeted in the "action" attribute of the form element. The method attribute identifies one of two ways the data can be sent along with the web page, either via "POST", or "GET" Neither of these is not part of PHP, but of the HTTP Protocol.

If the method attribute of the form is left empty, "GET" is the default. The "GET" method sends data along in a visible manner, strung after the file name, in a series of characters call the "querystring". For general purposes, we use POST to send data via forms, and GET to send data loaded in the querystring.

Inside the "querystring" are a succession of "name/value" pairs. These pairs indicate data that is sent, along with a word to identify what the data is. Below is a typical querystring:

blah.php?toy=ball$color=red$size=small

The data can be split apart at the page that is targeted with the "action"attribute of the form element. A typical form tag that could look like:

<form name="myForm" action="blah.php" method="GET">

The form elements (input fields, textboxes, checkboxes, etc.) are what make up the information that is sent along with the form. The "name" becomes the identifier of the item, and the "value" becomes the data itself, as entered by the user. As the user types the "value" that data is stored and sent along for processing.

In most cases, you will want to use the "POST" method of sending data, because it is not so readily visible to the user, and is therefore a bit more secure. The "GET" method is also useful, but is usually used in a different way. I can place a link on a page, and include the "Querystring" data, which I dynamically set on the form. When the user clicks on that link, the data is therefore passed from page to page without the use of forms!

The Formhandler

Whether the data is sent via POST or GET, upon submission, data is sent from the form to another PHP (or other) page, sometimes called a formhandler, because the page is designed to "catch" the data at the other end, and perform some activity (handle it). Activities include accessing a database, writing a cookie to the user's browser or sending an email. Data that is not handled properly at the moment of submission is lost forever.

At the moment the form is submitted, PHP code on the formhandler can "catch" the data and store or process it. The data as submitted by the user takes the following shape on the formhandler:

$_POST['varName']

$_POST in this case indicates the data was sent via POST instead of GET. The 'varName' is the name of the form element on the form itself. These must match precisely (case sensitive) or no data will be captured.

To get the data input by the user into a variable for processing on the form handler side, an example would look like:

if(isset($_POST['FirstName'])
{
     $myVar = $_POST['FirstName'];
}

The above example uses the function "isset()" to determine if there is data coming from the form for this form element. We frequently check for data sent by the user. If required data is not sent, we can redirect them (push them forcibly) back to the form for proper entry.

Feedback

Once a user has entered data in a form, we need to respond to them in some way. We'll call that feedback, for lack of a better term. If a person attempts to login and provides incorrect credentials, we would need to let them know. After the data is 'handled' on the formhandler, the response back to the user is formulated. The user is usually redirected to another page. For example, on successful login, we could forward a user to their profile page, to update their information. If they do not provide proper credentials, we'll redirect them back to the original form, with information on how to proceed.

Maintaining State

The web is by default a stateless environment, which means that every time we hit a web page, it looks like the first time for the server. There is no inherent way to determine if user has it a web page several times, or just one time. When we work with a web application, we will need to keep track of each individual user, if they are logged into our application. Doing this is called maintaining state, wherein 'state' refers to whether a person is essentially logged in, or not. Two mechanisms to do this are cookies and sessions, both of which we will cover in depth later.

Postback

Since pages are dynamic, there is no reason why you can't post (send) the form data right back to the page you are on. This technique is actually used frequently. This means that the form, formhandler and feedback parts can all exist on one page, as well. When the users hits 'submit' the data is 'posted' (sent) back to the same page, hence the word, postback.

To illustrate, examine the following versions of a single page "postback" web application. In the first example, we ask the user to enter a number of tires to order:

The first time the user hits the page, no data has been sent, so the empty form is shown. Once the user enters data, it is submitted back to the self same page, which now acts as the formhandler. Since there is now data, the data can be checked with the isset() function, which allows us to 'process' the data, and feedback some info the data has been received.

The POST data is checked via isset() using a PHP conditional statement, in this case an if statement.

In the second example, we do some quick math regarding the number of tires ordered:

Invalid Data

The primitive application thus far does not defend itself from invalid data being entered. Try entering text data, and see what happens. Later on, we'll take care to validate the data as it is submitted.