If your only building a single web page, what pattern you choose may not matter much. However, if your building entire web application then choose carefully. I've said this before, PHP only renders one page at a time. I keep saying it because understanding that is key to building efficient PHP applications.
If you look around you'll find the most common pattern used in PHP applications is the Front Controller. It's used in CMS such Mambo and PHP-Nuke as a centralized controller. When used as a centralized controller, all request pass through one file. In the case of Mambo that file is index.php. It's also used in forums such a phpBB and Phorum as a uncentralized controller. When used as a uncentralized controller, requests maybe distributed between several specialized controllers. In the case of phpBB those would be files such as viewforum.php and viewtopic.php. Even though there are more than one controller, the individual files are acting as Front Controllers to many different pages such as individual topics.
Front Controllers are not difficult to implement. A less than simple example, taken directly form PHP-Nuke:
I guess PHP-Nuke still hasn't adopted register_globals off, so you need to know the $name variable in line 3 is from the URL query string. Lines 8 - 13 fetch some information about the module identified by $name. Line 14 determines if the module is active or not, admin see even inactive modules as you can see. Skipping down to lines 26 through 33, you can see how it loads this particular module identified by $name if view equals zero. But that's just the beginning the page is no where near rendered yet.
PHP-Nuke may not be a simple example of a front controller but it sure shows how Front Controllers are being misused. We're no where near rendering a page and have already included up to 5 files, connected to the database, executed at 2 database query and have included 34kb of functions the final page may or may not need. Is this really worth trying to replace the http server? After all isn't it the job of the server to server files?
With PHP the overhead associated with the Front Controller isn't a one time thing, it occurs on every page. That can add up as traffic increases. Nothing wrong with using Front Controllers as long as you understand the cost associated with using them with PHP. Remember this ain't Java, yet?
Well enough for now, next time maybe we'll take a look at Intercepting Filters and how they can help us.
If you look around you'll find the most common pattern used in PHP applications is the Front Controller. It's used in CMS such Mambo and PHP-Nuke as a centralized controller. When used as a centralized controller, all request pass through one file. In the case of Mambo that file is index.php. It's also used in forums such a phpBB and Phorum as a uncentralized controller. When used as a uncentralized controller, requests maybe distributed between several specialized controllers. In the case of phpBB those would be files such as viewforum.php and viewtopic.php. Even though there are more than one controller, the individual files are acting as Front Controllers to many different pages such as individual topics.
On a side note: Open Source software development tends to build on the work of previous projects. This of course avoids the common pit falls of reinventing the wheel. However, this method of software development doesn't seem to encourage diversity when it come to software patterns. Sometimes reinventing the wheel maybe a good thing?
Front Controllers are not difficult to implement. A less than simple example, taken directly form PHP-Nuke:
PHP Code:
<?php
//modules.php
1 require_once("mainfile.php");
2 $module = 1;
3 $name = trim($name);
4
5 if (isset($name)) {
6 global $nukeuser;
7 $nukeuser = base64_decode($user);
8 $sql = "SELECT active, view FROM ".$prefix."_modules WHERE title='$name'";
9 $result = $db->sql_query($sql);
10 $row = $db->sql_fetchrow($result);
11 $mod_active = $row[active];
12 $mod_active = intval(trim($mod_active));
13 $view = $row[view];
14 if (($mod_active == 1) OR ($mod_active == 0 AND is_admin($admin))) {
15 if (!isset($mop)) { $mop="modload"; }
16 if (!isset($file)) { $file="index"; }
17 if (ereg("\.\.",$name) || ereg("\.\.",$file) || ereg("\.\.",$mop)) {
18 echo "You are so cool...";
19 } else {
20 $ThemeSel = get_theme();
21 if (file_exists("themes/$ThemeSel/modules/$name/$file.php")) {
22 $modpath = "themes/$ThemeSel/";
23 } else {
24 $modpath = "";
25 }
26 if ($view == 0) {
27 $modpath .= "modules/$name/$file.php";
28 if (file_exists($modpath)) {
29 include($modpath);
30 } else {
31 die ("Sorry, such file doesn't exist...");
32 }
33 }
xx ...
?>
PHP-Nuke may not be a simple example of a front controller but it sure shows how Front Controllers are being misused. We're no where near rendering a page and have already included up to 5 files, connected to the database, executed at 2 database query and have included 34kb of functions the final page may or may not need. Is this really worth trying to replace the http server? After all isn't it the job of the server to server files?
With PHP the overhead associated with the Front Controller isn't a one time thing, it occurs on every page. That can add up as traffic increases. Nothing wrong with using Front Controllers as long as you understand the cost associated with using them with PHP. Remember this ain't Java, yet?
Well enough for now, next time maybe we'll take a look at Intercepting Filters and how they can help us.
Comment