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:
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 :-/
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:
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.