Hindsight is something something something

I didn't want to write a web framework, and in hindsight, it probably would have been better if I had learned one of the more mature web development frameworks such as CakePHP, CodeIgniter, or, if I had been writing my code in Python, Django or Pylons. There are also numerous Java based frameworks that I could have used. Now my code is lacking in a lot of the features of the aforementioned frameworks but, and this is the important part, I didn't need to read a tutorial or learn how to develop with my framework because it evolved with my application.

how it started
One of the requirements of the site I was developing was clean/beautified URLs. I didn't want to ever have a URL like www.example.com/something.php?foo=jezra&bar=lickter. It sure would be nicer is the URL was www.example.com/something/jezra/lickter. On a Windows IIS server this can be done with either a third party rewrite plugin or with a very well crafted 404 script. However, since most webserver hosts don't allow for third party plugins and I had a devil of a time with the last few custom 404 IIS script that I wrote, I decide to go with the Apache webserver which has a built mechanism for rewriting URLs.

There seemed to be two ways to rewrite the URLs. The first way was to break apart the URL and into a list of the page and it's arguments and let the page decide what to do with the request, thus www.example.com/something/jezra/lickter would get directly rewritten as www.example.com/something.php?foo=jezra&bar=lickter and something.php would handle the request. The second way, which I decided to use, was to have a controlling script that would take all of the arguments of the URL and load a specific class and pass arguments to the class. In this way, I could define a default class that has the capabilities to handle database connections as well as handling text output to a template system for user interaction. Thus a request for www.example.com/something/jezra/lickter would actually load index.php and the index script would make a new instance of the "something" control class and pass the class the arguments "jezra" and "lickter". Upon creating the "something" instance, the parent class gets initialized and it is the parent class that handles the templating system and database connections.

What is being used
To handle the template system, I am using Tiny But Strong. Actually, the parent control class loads a wrapper class that in turn handles the tinybutstrong template. Through the extension of the parent control class, the individual controls are able to set template variable as well as pass arrays for duplication of tabular data. By using a wrapper class to handle the template system, I will be able to change template systems in the future, without having to rewrite the code for the various controls, by rewriting the code of the template wrapper.

Currently I handle database abstraction through a PDO (PHP Data Object) in the parent control class and this works fine for my needs. Moving forward, I should take greater advantage of the various PDO functions.


What's Missing
Lots of things.

What bugs me
If and when I need to make asynchronous javascript calls, I have been using PHPLiveX to creation of the browser specific javascript code and I would prefer for the server not to have to rewrite the URL, parse code, and process a template everytime there is an AJAX call to the server.

Basic Layout

• index.php // the main controller that handles all rewritten URLs
  
• controls // a directory that contains all of the includable controls, all controls are named after the first part of a requested URL
  
• javascripts // a directory of javascript files, all files are named after the first part of a requested URL
  
• styles // a directory of css files, all files are named after the first part of the requested URL
  
• templates // a directory of templates that are filled with data and sent to the users browser
  
• classes // a directory of class for creating controllers, templates, and database connections
  
• favico.ico // an icon to send to the web browser
  
• config.php // a php file that contains configurable information for database access and file path location
  
• .htaccess // an Apache file that contains rewrite rules
  

Ideally, all of the config information would be outside of the server's webroot folder.

Why
Why not? It was a fun and useful learning experience.