For Some Reason I Am Writing a Framework
Posted by Kurt on Wednesday, April 28, 2010 in category:
Well business has been pretty good, but the work has either been sensitive or pedestrian. I haven’t had the time or the reason to develop an interesting or challenging web project for about a year now. The paradigm… *dons shades* has changed *walks away as The Who destroys your ears*. Recently we decided to develop some sort of project management solution for Outside The Lab that would contain a superset of the features from the MML Invoicing System. The only problem is that the entire codebase for that thing is garbage and unusable. It contains zero separation of code and logic from design and layout. It is a paragon example of spaghetti code and it’s glorious in a weird, trainwreck kind of way.
Since then I’ve taught myself some Python and revamped my video host with Django (Link). I hadn’t had experience with the MVC design pattern although I knew the theory. Django really drove the point home and forced me to use it. I had such a wonderful experience that I wanted to be able to code the same way in PHP, but after trying CakePHP and CodeIgnitor, I was still wanting. These frameworks tried to do too much. I just wanted something that would abstract the database stuff away for me and let me do my own thing with the controllers and views. Something really minimal. Now maybe there is something out there like that, but I couldn’t find it. Plus, I figured this would be a great learning opportunity. My initial plan is detailed below for my own reference and for others who may be interested.
Andy and I sat down and figured out what functionality we wanted in the project management system and thus the data we wanted to store. I created a schema on paper that is decently complex and will serve as a good test case for this framework.
I spent some time today thinking really hard about how Django does the database stuff and why I liked it so much. Basically it does the following:
- You define a number of models that extend the base model class
- You run a script that automatically creates tables in your database from these models
- You access all your data from an object, run filters, and sort using methods in the base models class
- All this time, the model has been building an SQL query which is not executed until you access the data itself. It can do this because it knows the structure of the data in the database.
That last point is very important. I have to somehow create a way to codify the database schema that can be parsed by the framework to build SQL queries without hitting the database to take a look. There are a few possibilities for doing this using the PHP language, but short of porting the functionality of the Django Model base class over to PHP (which might not even be 100% possible), there was no way to create an easy-to-read and semantic schema in the PHP language itself. So I’ve created a parser that takes an INI file and creates a schema from it. The format follows:
[<table_name>] <field_name> = <type>(<default_value>)[,unique][,index] <foreign_key> = fkey(<foreign_table>)[,array] <enumeration> = enum(<value1>|...) ...
can be one of ‘string’,'text’,'integer’,'float’,'date’,'boolean’.
array is an optional parameter on foreign keys to indicate that there is a many-to-many relationship between the two tables.
An INI file. Cute. I’ve created a parser that dumps all this into a multidimensional array in the form
$structure = array("table1" => array(Field, Field,...), "table2" => array(Field, Field, ...))
where Field is a class that is little more than a struct to hold useful information about a field. I don’t know if this is the best way to proceed, but I’ve got a pretty good feeling about it. My goal is to create a Model class that can be passed a table name in the constructor and can use the information in the structure array to build queries. My next step though is to write the function that builds tables in the database from the information in the structure array so I can standardize how it will handle pivot tables and other stuff I haven’t thought of yet.
I intend to update this blog more regularly in the future with further developments with the project management system which entirely too long of a title. We’re working on it under the name Dorsia but that will absolutely not be the final name. We’re thinking YAMS (doesn’t stand for anything, or maybe we’ll invent an ironic recursive acronym) but really it could be anything.