Chained Request Handlers with Closures

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:
Continue reading

A Procedural Version of Comb

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 :-/
Continue reading

Comb Rewrite – A Quick Overview

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:
Continue reading

Pseudo-ENUM in PHP

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 though that it’d be nice to have a basic enum() function or construct, as a quick, convenient way to define a set of constants. There’s this option:

    define('ADMIN',     0);
    define('MODERATOR', 1);
    define('EDITOR',    2);

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

    enum('ADMIN', 'MODERATOR', 'EDITOR');
    // ADMIN == 0 
    // MODERATOR == 1 
    // etc.

Continue reading

Clean URLs – Basic mod_rewrite rules

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):

# 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:
Continue reading

Comb: auto_prepend_file, output buffering, and mod_rewrite

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.