PHP stands for “PHP: Hypertext Preprocessor”.
In computer science, a preprocessor is a program that processes its input data to produce output that is used as input to another program
Hypertext in this context means HTML. The idea was you write PHP code which is then sent to the preprocessor to execute and it sends you back HTML. Instead of having a static HTML file on your website you would have a PHP file which would be interpreted and converted into HTML. It was common for every page on a site to have its own PHP file. It made sense: users were migrating from static HTML pages which had their own files, so they would replace them with a PHP file.
Copy & Paste code duplication quickly became a problem. Code would be refactored into functions and stored in a .inc file, to be included by the .php script.
I remember a lot of my .php files looked like this:-
<?php
include("inc/common_funcs.inc");
if($_POST['submit']){
// form was submitted, do some logic
}
?>
<html>
… webpage + form goes here (and the form’s action would be the same page as this
</html>
There were a few other styles I remember too. One was to have a php file for the webpage/form and another for the processing of the form (ie the form’s action); this was a throw-back from the Perl CGI days where the static HTML would reference the .cgi file. Another was to pass a “cmd” or “action” variable and then have a switch statement to control the application flow.
<?php
if($_POST['submit']){
switch($_POST['cmd']){
case “save”:
// do the logic for “save”
}
}
?>
If you showed code like that to any PHP developer today they’d probably rip you a new one and say it’s crappy old school. But that last example should ring some bells - it’s pretty much the precursor to today’s frameworks’ Controller/Action style and fundamentally is the same thing (and probably runs faster). Sometimes I think that not a lot has changed in the PHP world from ten years ago :-).
I’ve been thinking about frameworks for a while. For me I’ve never really found one that clicks with how I work, or how I grew up learning PHP. I like things really simple - like loading a .php file in the browser and my code being executed. No routing, no dispatching, no jumping through a dozen files before my code runs. When I use frameworks the magic stuff scares and frustrates me; sometimes I feel almost claustrophobic - I’m stuck inside its way of doing things and I can’t get out.
A couple of years ago I designed a framework for a company who needed their “old school” code refactored. At the end of the project I remember turning to a colleague and exclaiming that I thought “it totally frigging rocks!”. What (I thought) it did very well was to make it easy for their internal developers to write new pages for their site. It took care of some of the setup stuff (bootstrap, loading config data, db layer) and then got out of their way.
<?php
class SomeHandler{
public function run($context){
$db = $context->getDb();
$request = $context->getRequest();
// do some logic
$person = $db->getPerson("Richard");
$context->setViewVar("person", $person);
$context->setTemplate('person.tpl');
}
?>
The developer writes their logic inside the run() method and has access to stuff like the DB or Request through the $context object. Their job is to write some logic and then set some variables for the view, that’s it. To give you some context, this class is instantiated by the “bootstrap” index.php file, based on some trivial routing, something like this:-
<?php
//bootstrap index.php
// setup context the context
$context = new Context();
$context->setDb($dbObject); // etc
$handler = "SomeHandler"; // replace this with some simple routing
$handler->run($context);
if($context->template){
$templateEngine->render($context->template, $context->viewVariables);
}
?>
As I remember it, URLS mapped 1:1: to handler files. The routing component was a little involved because it tied into another system, but for prototyping we used a router that directly translated the path to a class. So “/path/to/foo” would be the handler “Handler_Path_To_Foo”. We’re back to writing one .php file to handle one url, back to the old school. The templating system was there to use if they wanted (by setting a template in the $context object) but if not then no worries - whatever they echo’ed from within run() would be output.
I can’t claim this is amazingly complicated or innovative, but I think that’s kinda my point: it was dirt simple but it was really effective. The learning curve was practically zero for new developers, the system just augmented the basic offering of PHP (and made some “company specific” tools available to them).
I’ve got an archive of the project and today I counted the number of lines for the “framework” and it came in at about 600, including comments and empty lines which is tiny, almost nothing. But looking back on the code I think it’s some of the best code I’ve ever designed/written.
Why blog this now? As a part of APRIL I’ve been looking at the “server” component recently. This is the part of the library that helps a developer create their own RESTful webservice. In essence that means it’s “A Framework”: it handles the routing/mvc part of things (”Oh no, not another framework!”). I’m using the same sort of design for this as I did for the framework I talked about. It’s ultra-lightweight, I’m a bit embaressed to even call it a framework, but from the work I’ve done on it so far I’m getting the same feeling as I did before - it’s simple, fast and “feels” like old school PHP, in a good way.
