Chapter 3. Putting It All Together
Putting It All Together > Handling HTTP Requests
At this point you need to choose a web server to serve your content. For the purpose of this Short Cut, we chose to use the Apache web server (http://www.apache.org/). We chose it because it is easy to understand, and it's the most commonly used web server at this time.[*]
[*] According to Netcraft's April 2007 Web Server Survey, Apache powers 58.50 percent of all active sites (http://news.netcraft.com/archives/2007/04/02/april_2007_web_server_survey.html).
The approach described on the following pages is rather unconventional for applications using PHP and Smarty, but it is an excellent and elegant way of implementing the MVC pattern.
Let's start with a simple filesystem layout. This filesystem layout is flexible, and you should feel free to change this example to fit your needs whenever necessary:
app - lib - smarty - pear - apis - smarty - SOAP - ... - handler - config - docroot - cache - smarty_compiled - smarty_cached - other_cache
According to this layout, the Smarty template engine will be installed in app/lib/smarty and PEAR will be installed in app/lib/pear. To run the following examples, make sure the app directory is in your PHP include path.
The following code exemplifies how to add a new path to your PHP include path:
<?php ini_set('include_path', ini_get('include_path') . ':/path/to/your/app'); ?>3.1. Handling HTTP Requests
A single PHP script handles all HTTP requests. This script is responsible for choosing the right template and loading the required PHP code. We'll call it handler.php from now on.
There are two ways to deliver all the requests to the handler.php script, either through Apache's mod_rewrite module or through PHP's auto_prepend configuration directive.
3.1.1. Using Apache's mod_rewrite
mod_rewrite is considered by many to be the Swiss army knife of Apache. It consists of a regular-expression-based engine that parses URLs and rewrites them on the fly.[
] The way to rewrite this depends on how the module is configured.
[
] More information is available at the Apache HTTP Server web site, in the mod_rewrite section (http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html).
First of all, make sure the Apache web server has the mod_rewrite module enabled by looking at the Apache configuration file (usually httpd.conf).
Apache configuration directive to enable mod_rewrite:
RewriteEngine on
Also, configure Apache to handle .php files as PHP scripts. You can do this globally or only on some virtual hosts:
AddType application/x-httpd-php .php
Now configure mod_rewrite to pass all the requests to the handler.php:
RewriteRule ^(.*)$ /path/to/your/app/handler/handler.php
These steps cause all requests to the application to be handled by the handler.php script located under /path/to/your/app/handler. Because the script actually being executed is not the one that's being requested, you can find the requested URI in $_SERVER['SCRIPT_URI'] PHP variable.
The greatest advantage of this approach is that the requested URI doesn't have to exist. The only disadvantage is that you have to handle some of the things that the web server normally would do, such as testing whether the path is valid.
Using "Nice-Looking" URLsmod_rewrite makes it very easy to use so-called "nice-looking" URLs like http://example.com/book/read. Because all URL requests are passed through the handler script, it's very easy to write simple rules in PHP that decide what to do for a given URL. |
3.1.2. Using PHP's auto_prepend configuration directive
PHP has the capability to configure a script that is automatically called before every other script is executed. This option makes it very easy to "attach" a script to every HTTP request.
Because you want to handle both PHP and HTML files, you should configure Apache to handle both .php and .html documents as PHP scripts:
AddType application/x-httpd-php .php .html
Configure PHP to prepend the handler.php script to every file handled by it in this case, all the .php and .html documents.
You can do this in one of two ways, either in the php.ini PHP runtime configuration file or in the Apache configuration file using the PHP's php_value configuration directive.
Let's first see how to change the php.ini file:
auto_prepend_file = "/path/to/your/app/handler/handler.php"
The Apache configuration directive is not much different:
php_value auto_prepend_file /path/to/your/app/handler/handler.php
This method has the significant advantage of allowing the use of Virtual Host-based configuration.
Using PHP's auto_prepend directive allows requests to be mapped directly to the templates under the document root, making it easy to give access to the web design team and to give them flexibility on the site layout.
The only disadvantage is the lack of "nice-looking" URL support such as is in the mod_rewrite approach. Also, the requested URI path must really exist in the filesystem.
As with the previous method, the requested URI can be accessed through the $_SERVER['SCRIPT_URI'] PHP variable.
3.1.3. The handle.php script
This is the script where all the logic resides. It needs to be as simple and flexible as possible, and it must go through a series of tasks.
The following list shows all the tasks that the handler script performs:
-
Handles the request
-
Decides what to do with the request
-
Instantiates all required objects
-
Registers all needed information on the Smarty engine
-
Displays the appropriate Smarty template
-
Exits
Here's a possible handler script that encapsulates some of the previous actions into external helper classes:
<?php // Initialize the Smarty environment require_once 'lib/apis/smarty/SmartyInit.php'; // Load the SmartBook class require_once 'lib/apis/smarty/SmartBook.php'; // Display the required template $smarty->display($_SERVER['SCRIPT_FILENAME']), ?>
Many of the decisions that need to be made can and should be specified in your application configuration files, instead of being written inside your scripts. We will talk more about this later.
