I've not read thoroughly through the entire article (time is money) but I do however have a few comments to offer up. Firstly, the filesystem structure itself; why is there a folder named includes when some things in there aren't simple PHP files to be included into others (e.g. the js folder)? A more suitable name would suffice, or indeed a complete separation of groups of files serving different purposes (javascript, css might be better suited outwith the PHP files' folders).

A next point, and one I won't labour too much, is the way you have written the various DB-related classes. To me at least, whether you did this knowingly or not, it all seems very MySQL-centric in how things are done. You could certainly do with working with a wider group of databases and seeing which common methods are really needed, and those which are more tailored to working with MySQL in particular.

Next, your autoloading and factory method. Why have both? Why separate the two? It's not my point to provide answers right now but it's something to consider. I will, however, note that you can only define a single __autoload function. It might (read: will) be easier to use the SPL library (e.g. spl_autoload_register) to keep the DB autoloading separate from any other autoloading which might be needed elsewhere in your project.

For the configuration file, I'd like to see things simplified much more. Have separate config files for different jobs. For example, one for the MySQL database settings, another for SQLite database settings, yet another for caching settings (if that were to be part of your application), etc. Keep the variable names within those files simple (just plain $config works fine) and make use of the include-scope when loading/using the configurations (if that's over your head, I'll explain at a later date).

Anyhow, there are some comments to tide you over until I can really sink my teeth into this come september! :)

__________________
salathe@php.net