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:
- Form
- Formhandler
- 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!
Superglobals
In a previous lesson we discussed how constants are global, meaning they are always available to any PHP code once they are defined, even inside user created functions. Since constants are global, PHP uses the word superglobal to identify data that is pre-defined by PHP, and also available in a global manner. To identify a superglobal, PHP uses $_ to start the name of the superglobal, then an upper case keyword like POST, GET, SERVER or COOKIE for example to identify the type of data. The currently available data sent via the POST method then as a PHP superglobal would be $_POST, and the specific form it would take for data sent via POST that was a user typed field named 'myName' would look like: $_POST['myName']. Here's more on superglobals
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 is captured in the $_POST superglobal via 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. Note the square brackets around the variable name. This indicates the data is part of an array (set) which we'll cover soon.
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. After the data is 'handled' on the formhandler, a text response back to the user is formulated.
The type of feedback generated will vary based on the application. A typical formhandler working as a contact form may send an email to the site's webmaster, and then thank the user.
If the formhandler is designed to verify a user's identity it would compare the info entered by the user to what is stored in a database. If the data matches, we could forward a user to their profile page, to update their information. If they do not provide proper credentials, we could 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 hit a particular web page several times, or just one time. When we work with a web application, we'll 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, and who they are. Two mechanisms to do this are cookies and sessions, which are available in most server side programming languages. In PHP cookie & session data are available via the superglobals $_COOKIE and $_SESSION. We could store identifying data in a $_SESSION variable that will be specific to this single user. When we work with a page we'll view the contents of this $_SESSION to see who is currently on our page.
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 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.
