One of the problems with naming request handlers to match the incoming request method, e.g., GET, POST, PUT, DELETE, is that there’s an obvious potential for accidentally re-declaring that function. At this point in time, there are no pre-existing functions in PHP core that are named get(), post(), put(), delete(), head(), options(), trace(), or connect()…but that’s no guarantee that there won’t be in the future, or in a 3rd party extension/library that you may be using.

To get around that potential name collision, I could do a few things:

• Have a fixed prefix for those functions, e.g., doget(), dopost(), etc
• Have a user specified prefix that defaults to “”. So you could write your app with get(), post(), etc, or specify “do” in the init and use doget(), dopost(), or maybe specify “_” and use _get(), _post(), etc.
• Require the requested script to define a specific class with static methods for those HTTP verbs (with or without prefixes).

I wasn’t really satisfied with any of these options though. Prefixing the function names makes it less likely that a fatal function redeclaration would occur down the line, but technically it’s not impossible. That’s where the dynamic prefixing comes in…it make sit easier to sort of move those functions out of the line of fire, but they’re still in harms way. I’d rather extract them from combat altogether, so to speak.

The cleaner solution of those three options, IMO, would be to define a single class in every single one of the requested scripts. Something like:

1
2
3
4
5
6
7
8

<?php
class comb_handler 
{
    public static function get()    { ... }
    public static function post()   { ... }
    public static function put()    { ... }
    public static function delete() { ... }
}

Then Comb would just check to see of the requested method exists, and run it if so. While that would pretty much solve the function name collision problem, it feels very hackish to me. You’d essentially be using a class for nothing more than its namespace. After a bit of brainstorming I remembered that PHP 5.3 introduced closures. So instead of the request script looking like this:

1
2
3
4
5

<?php
function get()
{
    echo "hi";
}

I could do this:

1
2
3
4
5

<?php
comb_handle('get', function()
{
    echo "hi";
});

What I like about this approach is that instead of defining a specific request handler, I can define a bunch of them as closures and have comb_handle() just stick them all in an array. Then when it comes time to run the request methods, I can just loop over that array of closures and run them one after another. comb_handle() would look something like:

1
2
3
4
5
6
7
8
9
10
11
12

 
function comb_handle($method, $function)
{
    /**
     *  if comb were an extension, this variable would 
     *  only be accessible within the extension itself.
     *
     * $method is one of GET, POST, PUT, DELETE, XHR
     */
    global $method_chains;
    $method_chains[strtolower($method)][] = $function;
}

So imagine a GET request comes in for /session/login.php. The following scripts would get included (if they all exist):

/prepend.php
/session/prepend.php
/session/login.php
/session/append.php
/append.php

In each of those scripts, you can define handlers for any request method you want. To illustrate this, you could do the following in each of the scripts above:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

/* /prepend.php */
<?php
comb_handle('get', function() {
    echo "one! ";
});
 
/* /session/prepend.php */
<?php
comb_handle('get', function() {
    echo "two! ";
});
 
/* /session/login.php */
<?php
comb_handle('get', function() {
    echo "three! ";
});
 
/* /session/append.php */
<?php
comb_handle('get', function() {
    echo "four! ";
});
 
/* /append.php */
<?php
comb_handle('get', function() {
    echo "five! ";
});

Then after Comb includes those scripts the $method_chains array will look like:

1
2
3
4
5
6
7
8
9

array(2) {
  ["get"]=> array(5) {
    [0]=> object(Closure)#1 (0) {}
    [1]=> object(Closure)#2 (0) {}
    [2]=> object(Closure)#3 (0) {}
    [3]=> object(Closure)#4 (0) {}
    [4]=> object(Closure)#5 (0) {}
  }
}

Comb would simply do a foreach over $method_chains['get'] calling each closure, and you’d see this in your browser:

one! two! three! four! five!

So that’s the direction I’m heading now. That obviously means that Comb will require PHP 5.3 from this point forward, but another advantage of doing so is using namespaces to clean up these ugly comb_* prefixed functions. Some folks might not agree, but to me, this:

1
2
3
4

<?php
use comb as c;
c\handle('get', function() {});
c\handle('post', function() {});

…feels cleaner (though weirder) than:

1
2
3

<?php
comb_handle('get', function() {});
comb_handle('post', function() {});

Might as well start getting used to using namespaces though. I believe they’ll be getting much more common over the next year or two.

I wrote up a quick summary of all the comb_* functions. Check it out:

Comb Function Reference »

I think this is the third time I’ve re-tooled the guts of Comb. The main idea is still the same, but the default behavior is a little different, and it’s not object-oriented at all. My goal in doing it this totally procedural way is to make it possible to build it as a PHP extension, thus configuring its default behavior via httpd.conf, .htaccess, or php.ini. Not that making it an extension means that I can’t use objects…I just didn’t really feel the need at this point. Unsurprisingly, I may change my mind later :-/

Setup & Configuration

Comb still runs using the same overall lifecycle process as before, and at this point you still need to auto_prepend_file that bootstrap script. So your vhost would look pretty basic:

1
2
3
4
5
6
7
8
9

<VirtualHost *:80>
    ServerName example.com
    DocumentRoot /sites/example.com/www
 
    <Directory /sites/example.com/www>
        Options -Indexes, FollowSymLinks
        AllowOverride All
    </Directory>
</VirtualHost>

/sites/example.com/www/.htaccess would contain:

1

php_value auto_prepend_file "/sites/example.com/bootstrap.php"

… and /sites/example.com/bootstrap.php looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

<?php
    // comb_* functions are all defined in here...
    require '/www/example.com/comb.php';
 
    // set config values via php 
    // ...or in .htaccess using php_value, if comb was built as an extension
    $opt = array();
    comb_init($opt);
 
    // find includes, run REQUEST_METHOD function, e.g., get(), post()
    comb_run();
 
    // render templates if enabled
    comb_render();
 
    // send headers, flush buffer
    comb_send();

That first comb.php that’s being included is the library itself, and would ideally just get loaded as an extension. Even this bootstrap script would be written into the extension and run implicitly if it’s enabled for the vhost. But until I get brave enough to learn how in the world to translate this stuff into C, it’s going to have to exist in PHPland.

Application code

So now we write a “web application” that runs on Comb. I’ll create the following file in the document root (/sites/example.com/www), called index.php:

1

<h1>hello, world!</h1>

That will do exactly what you think it does, as will both of these:

1
2

<?php
    echo "<h1>hello, world!</h1>";

1
2
3
4
5

<?php
function get()
{
    echo "<h1>hello, world!</h1>";
}

And this is where it gets interesting; that get() function was defined, but I obviously didn’t call it explicitly. That’s done automatically in the comb_run() function. If a function exists that matches the incoming request method, it’ll get called, otherwise any output that’s sent will either get buffered and plugged into a template during rendering (if buffering is enabled), or immediately sent back to the client (if buffering is disabled).

Templating

Templating is also automatic. You can change index.php to be:

1
2
3
4
5
6

<?php
function get()
{
    // assign a var to be extracted into the template
    comb_set('title', 'hello, world!');
}

…then create a new file beside it in the document root called index.tpl.php:

1

<h1><?=$title?></h1>

That template file gets detected automatically in the comb_render() function, basically by looking for a file whose name is {script_basename}{template_extension}. The default template extension is set to .tpl.php but that’s configurable, so you can set it to .tpl or .phtml or whatever you’re accustomed to.

For shared templates (e.g., header & footer) the most common practice is to explicitly include them in each template that uses them, like:

1
2
3
4
5

<?php include "header.tpl.php"; ?>
 
<h1><?=$title?></h1>
 
<?php include "footer.tpl.php"; ?>

…which makes you end up with a lot of code duplication if you have many templates using that header/footer combo. I’m personally fond of the layout approach, i.e., a single wrapper template that plugs the wrapped content into place. To accomplish that, output buffering is pretty critical, and there has to be some mechanism in place in the layout template to grab the contents of the buffer. For that, there’s the comb_buffer() function. It’s used like so, in a new template file (also in the document root) called layout.tpl.php:

1
2
3
4
5
6
7
8
9

<html>
<body>
Header stuff
 
<div><?php echo comb_buffer(); ?></div>
 
Footer stuff
</body>
</html>

This will take the output rendered by index.tpl.php and drop it into that div. No need to include anything within the requested template. The comb_render() function not only auto-detects the requested template based off the requested script’s basename, but it also auto-detects the layout. If {layout_name}{template_extension} doesn’t exist (both configurable, “layout” and “.tpl.php” are the defaults), it simply won’t get wrapped.

Directory-Based Filtering

One of my primary goals with Comb is to keep the application simple by relying on as much web server work as I reasonably can. Organizing the application in simple, reasonably-named directories makes this very easy, because there’s no need for an explicit dispatch method that 1) parses the request URI, 2) processes user-defined routes to find a matching controller/handler, 3) instantiates and runs the controller/handler.

To get around this explicit routing/dispatching, Comb simply looks for any prepend or append files in each directory leading down to the requested script. In other words, a request for /account/index.php will actually end up running the following scripts in this order, if they exist:

1
2
3
4
5

/prepend.php
/account/prepend.php
/account/index.php
/account/append.php
/append.php

I’ll refer to this as the execution chain. The prepend and append filenames are also configurable. This enables you to organize your code in such a way that any scripts that require common pre- or post-filtering can simply be placed in the same directory. For example, if the /account directory can only be acessed by authenticated users, your /account/prepend.php script may look like:

1
2
3
4
5
6

<?php
    // assume $user was created in /prepend.php
    if ( !$user->isLoggedIn ) 
    {
        comb_redirect('/login.php');
    }

The comb_redirect() function does three things: 1) adds a Location: header pointing to the specified URL to the internal headers array, 2) halts the execution chain, and 3) turns off rendering. This causes none of the proceeding script in the execution chain to get included, so the comb_run() function will return to the bootstrap script. When comb_render() gets called, it first checks to see if rendering is enabled…it’s not anymore thanks to comb_halt(), so it returns to the bootstrap immediately. Then comb_send() is called, which first sends out any user-specified headers (e.g., Location), then checks to see if rendering is enabled. If so it flushes the buffer…but it’s not enabled, so comb_send() thus returns and the lifecycle is complete.

That’s a crash course in what I’ve got so far. There’s a bit more that I’ll cover in my next post, but in the mean time if you’ve got any feedback on this approach, please let me know…I’m interested to hear other folks’ opinions.

Sean Kerr built and currently maintains a simple web application engine (’tain’t a framework!) called Redline. He and a few other guys I know (Wess & Brandon) have raved about the deadly speed+simplicity of it for quite awhile now, so I thought I’d give it a go with a site I’m building for my day job.

To begin, I set up a basic vhost container in Apache in which to drop the RL code:

1
2
3
4
5
6
7
8
9

<VirtualHost *:80>
    ServerName redline.local
    DocumentRoot /sites/redline.local/www
 
    <Directory /sites/redline.local/www>
        Options -Indexes, FollowSymLinks
        AllowOverride All
    </Directory>
</VirtualHost>

Then I create the site directory, download the Redline package from Sean’s site, and unzip it:

1
2
3
4
5
6

 drew@server$  mkdir -p /sites/redline.local
 drew@server$  cd /sites/redline.local
 drew@server$  wget http://code-box.org/work/redline-0.1.zip
 drew@server$  unzip redline-0.1.zip
 drew@server$  cp -R redline-0.1/* .
 drew@server$  rm -rf redline-0.1/

At this point, the contents of my /sites/redline.local/ directory is:

1
2
3
4
5
6
7

 cache/
 config.xml
 docs/
 lib/
 modules/
 tags/
 www/

Redline expects all requests to be rewritten through the document root’s www/index.php script in order to properly dispatch each request. To get that running right, I create the following .htaccess file under www/:

1
2
3
4
5
6
7

RewriteEngine On
 
# don't rewrite the index script, or any CSS, javascript, or image files
RewriteRule ^(index\.php|js|css|images) - [NC,L]
 
# everything else goes through the index bootstrap
RewriteRule (.*) index.php/$1 [L]

Another problem I ran into is that the dispatcher parses $_SERVER['PATH_INFO'] in order to determine what’s being requested, but for some reason on my VirtualBox server (Ubuntu 8.10, Apache2) I don’t have that variable available. I googled a bit to find out how to get it set, but the most sensible solution (AcceptPathInfo On) didn’t pan out either. Instead, I cracked open Redline’s config.xml and told it to use REQUEST_URI instead of PATH_INFO:

1
2
3
4

...
    <!-- request path details -->
    <define name="RL_PATH_INFO">REQUEST_URI</define>
..

Redline is built to parse that XML config and generate a PHP script that gets stored under the cache/ directory, which means that directory will need to be writable for the user that Apache runs as (www-data, nobody, apache, etc). There are a few ways to handle this, but the quick and dirty option is to just chmod 777 cache, which effectively gives every user on the server read/write access to everything in that directory. Since I own the whole machine it’s not a security concern, but in a shared environment you’d want to take a slightly less shotgun approach (assuming it’s an issue at all).

Next I edit my hosts file so that redline.local resolves to my server’s IP address, and I give it a test run by pointing my browser to http://redline.local/redline, which loads up the example redline module provided in the package. And what do I see?

Welcome to Redline

Yay! Next I’ll set up another module and explain what I’ve learned so far about routing.

I’ve been using Comb, my experimental PHP framework, for a couple of super-secret projects over the past few months (on those sporadic occasions when I actually write code), and it’s been evolving pretty dramatically. So much so that very little of the original code still exists. I’m still calling it “Comb” though, because the underlying idea is still the same. It’s too time consuming to describe the reasons why I changed each part, so suffice it to say the changes are essentially organizational. Instead I’ll just jump into explaining it from the ground up as it exists now.

To begin with, here’s the now-simplified Apache VirtualHost container that I’m using:

1
2
3
4
5
6
7
8
9
10
11

<VirtualHost *:80>
    ServerName      example.com
    DocumentRoot    /vhosts/example.com/www
    ErrorDocument   404 /404.php
 
    <Directory "/vhosts/example.com/www">
        AllowOverride All
        php_value include_path ".:/vhosts/example.com/www/lib:/vhosts/lib"
        php_value auto_prepend_file /vhosts/example.com/www/comb.php
    </Directory>
</VirtualHost>

The first four lines should be pretty self-explanatory, but for the rest:

7. Allow the full use of .htaccess files, e.g., for rewrite rules, etc
8. Set PHP’s include_path to the current working dir (when parsing templates), the application’s lib dir (for app-specific classes), and the system lib dir (for shared classes)
9. Prepend comb.php in the document root to every requested PHP script.

This Apache configuration ensures that every requested script will first run the site’s comb.php script, which is a very simple, application-agnostic bootstrap script, meaning it’s basically the same for every app that I build. In fact I could just have one copy of it in a central directory and prepend it from there, but I’d lose some potential flexibility that way. Though that could probably be coded around. Anyway, here’s where things get interesting… comb.php looks like this:

1
2
3
4
5
6
7

<?php
    require '/www/include/load.php';
    spl_autoload_register('load');
 
    $comb = new util_comb();
    $comb->run();
    $comb->send();

My standard autoloader is pretty simplistic; it just converts “util_comb” into “util/comb.php” and tries to include it based on the include_path set in the vhost container.

The util_comb class encapsulates all the crucial routing and response rendering logic. The constructor parses the request URI into its segments and loops over them looking for any files called prepend.php and append.php. If they exist, they’re added into an array that I refer to as the inclusion list. To visualize this, imagine a request for /user/profile.php?name=drew. The vhost will start by running comb.php, and the following scripts will get added to the inclusion list if they exist:

/prepend.php
/user/prepend.php
/user/profile.php
/user/append.php
/append.php

…in that order. The idea is to sort of mimic the way Apache finds and parses .htaccess files that are (possibly) in each subdirectory.

The next method that’s called, $comb->run(), simply loops over the inclusion list and include()s each one of them.

Finally, $comb->send() is called, in which the response is created and sent. This is where template rendering or redirecting takes place.

My next few blog entries will go into the details of the inclusion list, how I’ve set up template rendering, and how to get clean/friendly URLs working.

I’ve been working on a project lately where I’m rolling my own basic role-based access control (RBAC) system. In experimenting with different ways to handle the role definitions, I realized that it’d be pretty nice to have a basic enum() function or construct, as a quick, convenient way to define a set of constants. There’s this option:

1
2
3
4
5

<?php
    define('ADMIN', 0);
    define('MODERATOR', 1);
    define('EDITOR', 2);
?>

but that isn’t exactly succinct. I’d rather have something like this:

1
2
3
4
5

<?php
    enum('ADMIN', 'MODERATOR', 'EDITOR');
    // ADMIN == 0 (true)
    // MODERATOR == 1 (true), etc.
?>

You can kind of mimic the enumerated values with arrays like so:

1
2
3
4
5
6
7

<?php
    $roles = array(
        'ADMIN' => 0,
        'MODERATOR' => 1,
        'EDITOR' => 2,
    );
?>

but having to specify those values is just tedious. There’s an easy trick to get around that though:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

<?php
    $roles = array(
        'ADMIN',
        'MODERATOR',
        'EDITOR',
    );
 
    $roles = array_flip($roles);
 
    /*
    Array
    (
        [ADMIN] => 0
        [EDITOR] => 1
        [MODERATOR] => 2
    )
    */
 
?>

Which is cool, but I want constants, not just array values. Which is cleaner?

if ($role == $roles['ADMIN'])
if ($role == ADMIN)

So a bit more digging, and I found that APC can turn an array into a bunch of constants in one fell swoop!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<?php
 
    /**
     * Try loading the constants from APC
     */
    if (!apc_load_constants('roles'))
    {
        /**
         * they aren't in APC, so make 'em and define 'em
         */
        $roles = array_flip(array(
            'ADMIN',
            'EDITOR',
            'MODERATOR'
        ));
 
        apc_define_constants('roles', $roles);
    }
 
    /**
     * Now we've got enumerated constants...
     *  ADMIN == 0
     *  MODERATOR == 1
     *  EDITOR == 2
     */
?>

Obviously you need APC to make this work. One great thing about using apc_load_constants() is that you get a modest speed boost because you don’t have to define() all of your constants every time the script runs. Another benefit is that you can load up your array of roles (or whatever your constants are, e.g., permissions, etc.) from a database or other dynamic source, and convert them into global constants with one function call.

Now what would be even cooler is if you could tell apc_load_constants() to load the constants into a specific namespace, maybe something like:

1
2
3
4
5

<?php
    apc_load_constants('roles', true, 'drew');
 
    echo "ADMIN's value: " . drew::ADMIN;
?>

Though I assume that would require at least PHP 5.3.

I’ve been using Comb with a few more projects recently. The main point of Comb is to structure the code in such a way that the request handlers get accessed directly via Apache, as opposed to rewriting the entire URL, and making PHP dynamically include or instantiate a request handling class (i.e. Action, Command, etc).

For example, you might have a registration form that is accessed like this (pseudo-HTTP):

1
2
3
4
5

# display the registration page...
GET  /register.php
 
# registration form submits to...
POST /proc_register.php

I personally hate that naming convention because it reminds me of how I wrote code 5 years ago, and it’s just plain ugly.

Here’s a cleaner, friendlier approach that I’d rather use:

1
2
3
4
5

# display the registration page...
GET  /register
 
# registration form submits to...
POST /register

Yep, that’s a postback. And yep, there’s no .php extension used to access it, so some URL rewriting will be in order. I’ll add the following code into my virtualhost container in the Apache config:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# turn on the voodoo
RewriteEngine On
 
# if the incoming request has one of these extensions, 
# just serve up the file without rewriting anything
RewriteRule     /*\.(php|html|css|js|jpe?g)$ - [NC,L]
 
# just a little shortcut to make it easier to deal with 
# case-sensitivity
RewriteMap      lc      int:tolower
 
# make clean/friendly URLs work
# e.g., turn this:  GET /register
#       into this:  GET /register_get.php
# 
# and turn this: POST /register
#     into this: POST /register_post.php
#
RewriteRule  /(.*)  /$1_${lc:%{REQUEST_METHOD}}.php [NC,QSA,L]

After restarting Apache, I’ll create these two files to make sure the rewrite is working properly:

register_get.php

1
2
3
4
5
6
7
8
9
10

<html>
<body>
 
  <form method="post">
    Username: <input type="text" name="username" /><br />
    <input type="submit" />
  </form>
 
</body>
</html>

Note the form tag on line #4, it’s simply <form method="post"> without the expected action="/register" attribute. By leaving the action attribute absent or blank, the browser will simply submit the form back to the current address, i.e., a post-back.

Luckily our rewrite rule will see that the incoming request is a POST instead of a GET, so it’ll route the request into a different script:

register_post.php

1
2
3
4

<?php
    echo "posting registration form...";
    var_dump($_POST);
?>

Nothing magical happening in there, but the point is that mod_rewrite can be used to run different scripts based on the %{REQUEST_METHOD} variable, so you can organize the scripts according to the action being performed. It would even route PUT, HEAD, and DELETE requests to /register_put.php, /register_head.php, and /register_delete.php, respectively…assuming the HTTP client was capable of sending those requests (e.g., AJAX).

Jody clued me into a convenient method of paginating a result set from MySQL. Since he hasn’t blogged about it yet, I will >:-)

In the past, I’d issue two queries back to back, similar to this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

<?php
    $page = isset($_GET['page']) ? (int) $_GET['page']: 1;
    $size = 10;
    $offset = ($page - 1) * $size;
 
    $db = new mysqli("localhost", "drew", "mypass", "db");
 
    $sql = "SELECT username FROM user LIMIT $offset, $size;"
         . "SELECT COUNT(*) FROM user";
 
    $users = array();
    $total = 0;
 
    if ($db->multi_query($sql) && $res = $db->store_result())
    {
        // fetch this page of user records
        while (list($name) = $res->fetch_row())
        {
            $users[] = $name;
        }
 
        // fetch the TOTAL number of users
        $db->next_result();
        list($total) = $db->store_result()->fetch_row();
    }
 
    $pages = ceil($total/$size);
 
    echo "Total Users: $total<br>";
    echo "Total Pages: $pages<br>";
    echo "Current Page: $page<br><br>";
 
    foreach ($users as $u) echo "$u<br>";
 
    if ($page > 1) 
        echo '<a href="?page=', $page-1, '">&laquo; Prev</a>';
 
    if ($page > 1 && $page < $pages) 
        echo " | ";
 
    if ($page < $pages) 
        echo '<a href="?page=', $page+1, '">Next &raquo;</a>';
?>

Take note of Line #8. The first query grabs the specified page of results, the second simply does a full count of all rows so I could calculate the total number of pages.

What sucks, however, is if the query is more complex, especially if the various parts of it have to be dynamically generated, e.g., table joins, conditions in the where clause, etc. In such a case you’d have to change the second query to get rid of the column list SELECT column1, column 2... and make it SELECT COUNT(*). Also, you’d have to toss out any ORDER BY and LIMIT clauses.

MySQL allows you to simplify this extremely common scenario by using the FOUND_ROWS() function. In the above code, you can simply modify the query itself:

1
2
3
4
5
6
7
8
9

<?php
    // ... change this:
    $sql = "SELECT username FROM user LIMIT $offset, $size;"
         . "SELECT COUNT(*) FROM user";
 
    // ... to this:
    $sql = "SELECT SQL_CALC_FOUND_ROWS username FROM user LIMIT $offset, $size;"
         . "SELECT FOUND_ROWS()";
?>

The rest of the code remains the same and will give you the exact same results.

The speed of this approach can vary depending on how you have your table(s) indexed, and the complexity of the query itself. In other words, in some circumstances it may be faster to actually run the LIMITed query followed by the appropriate SELECT COUNT(*) FROM ... query as in the first example, but the primary benefit is in the simplification of the query itself.

I’ve decided to give a name to this barebones framework that I’ve been playing with for the past couple of months. I’m calling it Comb. Unfortunately it takes a long time to fully explain the thinking behind the name. Similar to Camber, however, the jist of it is simplicity; think “get the tangles out of my code”. Plus comb is a lot faster to say and type than MVCish-framework-based-on-autoprependfile-and-output-buffering.

My plan is to build the simplest web app framework that I can. I’m by no means an expert, and I don’t anticipate that this will end up being the best/fastest/most-convenient framework that will lay waste to the Zend Framework, or Symfony, or Kohana (or the mystical Redline! no link…it’s too mystical). I just want to start from the ground-up by making very few assumptions, and without ripping “inspiration” from the latest and greatest RAD framework. I want to end up with a simple base of code that I don’t have to learn how to love, and that can evolve with me without getting in the way. Basically this is all about me, but you can feel free to use it as well if it makes enough sense.

I’ve got a few projects in mind that I’m planning on being powered by Comb. The first is my Code Examples site, which will serve two purposes: it’ll be a place to host demos of basic code for the blog entries I write, and it’ll be a testbed for integrating new features into the framework. And yes, the code that runs the examples site is Comb itself. The other projects will be revealed in time…

I thought I might take a little step back here from my previous entry regarding my simplistic, not-all-that-original MVC using auto_prepend_file. I realized that I didn’t really explain why I occasionally get in that “there’s-got-to-be-a-simpler-way” frame of mind.

As I was building Camber, I made it a point to stick with an object-oriented design as closely as possible. The bootstrap script (i.e., index.php) simply sets up the basic environment, creates the main objects that are needed for the application, and starts things flowing. To re-cap, the whole life-cycle for a request in a Camber application is:

1. Create the Application object
2. Create the Controller object by passing in the Application
3. Call $controller->getResource() which returns a Resource object
4. Call $resource->run(), which returns the Response object
5. Call $response->send() to send the response back

In general, I like the way the application itself is structured. Although any given Resource class (which is basically just a collection of request handlers, i.e. get(), post(), delete(), put()) might be pretty complex, it’s fairly simple to figure out where each feature of the application should reside. Adding functionality to your application is really just a matter of writing new Resource classes and updating the templates appropriately. The thing that bothers me though is the routing process, i.e., determining which Resource needs to be instantiated for any given request.

Camber’s routing logic is handled within the Controller::getResource() method, but I pretty much ignored building any kind of regular-expression-esque routing language. Instead of having a declarative way of specifying which Resource to create, my neglect requires the author to decide how to perform that instantiation. Maybe a bunch of big, ugly, nested if()s that examine the incoming URL, or a switch() statement that does the same. You could even write your own regular expressions to match the various parts of the URL and decide which Resource needs to be created and run. I know. Shame on me for not building that mechanism into the framework.

Anyway, the reason that this kind of in-framework routing bothers me is that it is implemented in PHP (either pre-built within the framework itself, or (even worse!) by the author of the application). Not only does that seem unnecessarily bulky, but it also requires some kind of loading mechanism that looks up the appropriate request handler. This can be accomplished in a relatively uncomplicated way by putting all of the request handlers in a special directory (e.g., controllers/), then just require()ing the appropriate class file depending on what your routing method returned and instantiating it.

Is that really necessary though? Imagine a simple web application where an HTTP request for:

http://example.com/profile/display?name=drew

will result in the following code being executed (use your imagination to fill in the gaps):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<?php
    // ...routing code runs here...
    // determines the following from the request:
    //   $controller     = 'profile'
    //   $action         = 'display'
    //   $params['name'] = 'drew'
 
    require 'controllers/' . $controller . '.php';
    $controller .= 'Controller';
    $c = new $controller();
 
    // i.e., $c->display(array('name' => 'drew'));
    $c->$action($params);
 
    // ...finish up, send response...
?>

It’s not a whole bunch of code, but I don’t think it needs to exist at all. Basically, instead of mapping requests to request handler classes, loading them, instantiating them, and running them, I propose simply using mod_rewrite and the natural file system structure in the document root to run the scripts that are being requested. This way, instead of declaring and implementing routing rules in PHP, you’d just use the appropriate mod_rewrite rules. Instead of dynamically instantiating a request handler, you just let apache serve up the whichever PHP script happens to match the rewrite rule.

Obviously, this would mean that the request handler isn’t an object at all; it’s, for the most part, a regular old PHP script. Is that so bad though? There are definitely many conveniences that object-oriented request handlers can provide, such as using inheritance to specify things like authentication and authorization in the target request handlers. I believe, however, that it’s possible to abide by the same DRY (Don’t Repeat Yourself) principles for these specific requirements without relying on an unnecessarily complex object-oriented controller design.

The overarching idea here is to use the web server to handle as much of the grunt work of the application as possible before actually handing off control into PHP land.