It’s worthwhile to look at how this blog software will work internally. I’ve used this pattern on many many projects and it works for me.

First, as I’ve said repeatedly, there is no front controller. However, I do plan to have models, views and controllers. But I use those terms perhaps a little more loosely than others. I also eschew “frameworks” in favor of “toolkits”. A framework insists that you fit your software into it. A toolkit allows you to grab pieces from it to build the software the way you want. (No offense is intended here to framework advocates. I truly admire CodeIgniter and Drupal. I just don’t want to use them.)

Just in case there’s anyone reading this who doesn’t know what a “front controller” is, I should probably take a moment to explain. A “controller” (as I loosely define it) is that code which sets up a page to display and/or validate. It decides which view to use and which model to use, and acts as the “glue” for the other pieces. Controllers are usually fairly sparse. Most of the real code is contained elsewhere. A “front controller” is a controller designed to handle every single (or almost every single) page on a site. If you see a url like this:

http://example.com/index.php?something=1&other=2

you’re most likely looking at a front controller, which is usually an index.php file. The front controller looks at the query string that’s passed to it (as a GET variable) and determines which view and which sub-controller to call. Frequently, sub-controllers are actually methods of other controller classes. For example, you might have a “customer” class which has methods like “add_customer” or “delete_customer”. The front controller would know, based on the query string, which of the methods within a controller class to call. It would probably call that method and pass it the part of the query string it needs to do its job (like a customer number).

In any case, I don’t like front controllers (and for what it’s worth, neither does the creator of PHP, Rasmus Lerdorf; see his blog post on the subject). I prefer page controllers. In a page controller, the page functions as its own controller.

So in the case of Grotblog, any given page (like add_post.php) will contain setup code where it calls other code in to build a sort of framework of variables and routines useful for doing the other jobs of the controller. In our case, the first thing it will do is start up the session and call in the startup.php file.

The startup.php file evolved as a way to avoid calling 15 different code files before actually doing anything. I’ve seen many many frameworks do this. Codeigniter, bless its heart, does this. But my view is that if you’re going to need a bunch of code for every page you’re going to display, you might as well put it all in one file at the beginning, that you call on every page. This file will contain the error handler, a routine which will find any given file you want in the directory hierarchy, the code to read the configuration file(s), some commonly used routines useful for displaying things like menus, a class which automatically instantiates other classes as needed, etc.

Purists will complain that having all this unrelated code in the same file makes for a maintenance nightmare. I disagree. If you’re going to use this toolkit, learn what’s in that file so that if you ever need to modify it, you know where it is. And obviously, don’t put things like your date class in here; you’re not going to need it on every page. Only what you really need goes here. I can pretty much guarantee that I’m going to need the configuration variables for every page, so let’s put the configuration code here.

After the page controller calls in the startup.php file (include(‘startup.php’);), it should lay out any variables needed for displaying the page. Things like the page title, which template to use, etc. In addition, if you’re going to be validating POST variables on the return trip through this file, you should define those here, and call in any code needed to handle them. Once done with that, the page controller should call in the proper template to display. That template file will then start to display and call in the view you’ve previously defined. At that point, the page is fully displayed.

If you intend to use “reentrant” forms, as most PHP programmers do, you’ll want to put some branching, field/page validation code and similar code in the page controller. At some point, if the user has entered valid data on the page, the page controller will want to make a call to the appropriate model code to store the data.

That’s the simplicity of it. The view just displays the page data (forms, tables, etc.) within the context of the template. And the model stands between the database and the rest of the application, storing, modifying and deleting data from the database and the user.

See you next time.