In this article I explain to designers of dynamic Web sites the information flow between a user, a Web application, and its database back-end. I focus on the MySQL (www.mysql.com) database server, using PHP (www.php.net) as the scripting language and phpMyAdmin (www.phpmyadmin.net) as an interface to MySQL.
Traditional (non-Web) and Web applications differ in the way they transport data, both from/to the user and from/to the database. I will first contrast how the data flow is managed in both systems, and then present a sample Web application.
Non-Web Applications
Let's examine the sequence of events in a traditional application:
The user starts an application now it is running locally on his computer.
The application opens a file or makes a connection to a database server.
The application displays a GUI (graphical user interface).
The user interacts with the interface, making choices, using buttons, etc.
The application, which is still running, reacts to the choices (also called events), querying the file or the database, and modifying the image on-screen.
This step is repeated until the user closes the application.
Data flow
A few notes to describe non-web applications:
The application has a direct link to the data repository (database).
The GUI can use any facility that the underlying windowing system offers to present data and to interact with the user.
The application is always running (on the user's computer), ready to react and to modify the interface accordingly.
In most cases, the application is tied to the target operating system and windowing system; it must be installed on the user's computer and cannot be run on every platform. Think about the differences between MS-Windows and the Mac, or between different MS-Windows versions. We will call those limits the platform limits.
Web applications
There are situations where the platform limits of non-Web applications must be overcome. An on-line banking service would not want to force customers to use a particular computer platform, or have them install some software before accessing its services. The goal of the Web is to allow universal access to data.
In order to achieve that, we must understand the way of the Web of doing things and adhere to its standards. I will first show how data moves between the components, using a simple Web application.
Data flow
It is clear from the diagram that an application that is running on a user's computer does not have a direct access to the database, as all queries are done by the Web server:
Initial Table Creation
Our sample application enables a person to become a new member of a Kite club. This application uses the members table. We use phpMyAdmin's table creation facility to create this table:
After having created the table, we can run the sample code below to try the application.
The browser contacts the target Web server (www.domain.com) via the HTTP protocol (and its GET method).
The server sees that the document ends with .php, so it fetches kiteclub.php located on the server's file system, and hands it to the PHP module, which is part of the Web server.
PHP executes the script kiteclub.php. The script notices that it's the first time it has been called (more on this in the code below) and then sends XHTML code to the browser, to draw a form. We will see what happens when it's not the first time, a few steps below.
An important point to note here is that the script stops, dies, and no longer exists in memory. Now the user has a form on-screen and the Web server is doing nothing (for this user): it's not waiting for an answer.
The user enters some data and clicks OK. This triggers another HTTP transmission, this time with the POST method. In our example, the ACTION of the FORM is to call again kiteclub.php.
The server's PHP component starts over the execution of this script, and this time, the script notices that there is some data coming from a form.
The script makes a connection to the MySQL database server, which could be on the same server or somewhere else, using the function mysql_connect().
The script sends MySQL queries and checks the answers. In our case, information about the member is stored in the database, using the function mysql_query().
The script then generates another XHTML page, this time containing a confirmation for the membership. Then the script dies for the second time.
The dialog can continue here, depending on the complexity of the script.
Sample code
This is a listing of the kiteclub.php script:
<?php
// kiteclub.php
// sample application by Marc Delisle
// display standard DOCTYPE and headers
?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" dir="ltr">
<head>
<title>Kite club</title>
<body>
<?php
// The first time the script is called:
if (!isset($_POST['name'])) {
?>
<p><b>Welcome to the Kite club!</b></p>
<form method="post" action="<?php echo $_SERVER['PHP_SELF'];?>">
Please enter your name: <input type="text" name="name" /> <br />
and your email address: <input type="text" name="email" /> <br />
<input type="submit" value=" OK " />
</form>
<?php
// Second time, the values have been posted:
} else {
// connect to the MySQL server
mysql_connect("localhost","root","bingo");
// select the database
mysql_select_db("article3");
// insert the new member
mysql_query("INSERT INTO members (name, email) VALUES ('"
. $_POST['name'] . "', '"
. $_POST['email'] . "');");
// confirm the membership
$id = mysql_insert_id();
?>
<p>Thanks! you are now member #<?php echo $id;?></p>
<a href="<?php echo $_SERVER['PHP_SELF'];?>">Back</a>
<?php
}
?>
</body>
</html>
Stateless Model
A fundamental difference between non-Web and Web applications is that in the case of the latter there is no permanent connection between the application and the user's computer. The application is running on the server (in a controlled environment), and contacting a database server (probably behind a firewall) which normally cannot be reached by other means.
The HTTP model is called "stateless" because each transaction, i.e. each click, is independent from the others. A variable that was given a value in a previous execution of the script is simply lost.
To compensate for this loss of state, various things can be done:
Putting hidden fields in the form that are sent back to the next iteration of the script (POST).
Sending parameters to the script (?member=1234&lang=fr), using the GET method.
Using PHP's session mechanism, which maintains the state between each iteration of the script, by sending a cookie containing a session id which refers to a zone in the Web server where some variables were stored in the previous execution of the script, or by adding the session id as a GET parameter
By using either of these methods, next time the script is run, it will know what to do (for example, the user has selected two books and clicked the Check out button because they are ready to order).
Conclusion
Developing for the Web is fun and rewarding. It opens interesting possibilities for rapid development and deployment of applications. I hope to have demonstrated the differences between traditional and Web-based applications, and that you will join, not the Kite club but the club of happy PHP/MySQL application developers (and phpMyAdmin users).
