A couple of weeks ago we were given a project where a table had well over 50 fields. Immediately, I thought WTF, but then when I had a moment to think clearer about the size of the project, we suddenly thought of the idea of using the concept of “Don’t repeat yourself” to help us build the form, the insert queries, the update queries, the delete queries, etc; and reducing the amount of work needed.
Essentially, we wanted to get the database to do all the heavy lifting, by providing us with the code for CRUD actions without us having to do all that much… but then, things are never *that* easy…
The maxim of “Don’t repeat yourself” first came to full public prominence through the Rails framework. Built for the Ruby programming language, it promised the ability to reduce headaches and strain; many coders of different languages have built similar frameworks built upon the MVC (model-view-controller) approach to building websites.
For the many PHP programmers, there have been a steady increase of MVC/Rails-like frameworks such as CakePHP (for the advanced programmer) and CodeIgnitor (for people who don’t have the expertise that MVC requires), and each boast a similar kind of philosophy; essentially — why repeat yourself in doing similar actions, simply your actions and use them accordingly.
Although using Object Orientated programming is nothing new, and whilst it’s true that many PHP programmers have utilised a vast library of classes, libraries and extensions; the concept of don’t repeat yourself can confuse the novice, and can seduce some into believing that the framework can do all the work, when in reality – this is not really the case, especially for big sites.
The best example of this I can give is that, let’s say you have a database table called “customers”, and it has these properties;
Example:
“customer_id (int)
forename (varchar)
surname (varchar)
wages (int)”
Ordinarily, you would have to create the HTML form gadgets for each of the fields you want on your page; then type out each of the field names; then type out the processor part (ie: saving it)..
But why even do *any* of this? The database already has the fields; so why do you need to type them out thrice? CodeIgnitor, Cake and Rails use scaffolding to build the HTML form gadgets and create all the stuff you want, immediately.
Although we’ve only used CodeIgnitor briefly, the problem (as I see it), is the same; scaffolding. What is scaffolding? Well, essentially you give your framework the link to your database and it will construct the CRUD (create, retrieve, update and delete) actions for you; it will also wrap HTML form gadgets based upon the database table you want, vastly increasing speed of development.
We were going to use CodeIgnitor or CakePHP to use it; but because of the learning curve and the fact we had to get the project out real fast we had to work around the issue by thinking differently.
The falacy of scaffolding
The problem with scaffolding, as I’ve seen in CodeIgnitor, is that:
- Scaffolding doesn’t know which of your fields are Primary Keys, secondary keys, etc
- Scaffolding doesn’t know which of your fields to hide, which are required (ie: e-mail), or how to validate specific fields…unless you tell it to
- Scaffolding doesn’t know how to handle select boxes, multiple checkboxes, radio buttons and complex forms; it doesn’t know how to separate specific form regions into fieldsets
Although changing how the scaffolding isn’t really all that hard, and sure; you could do it… but the thing is, you shouldn’t have to.
The alternative: build it yourself?
So, we couldn’t use CakePHP (its built for PHP5 and our servers do not handle PHP5, nor will the host provide us with PHP5), we didn’t have time to learn Rails and we hadn’t the time to learn how to change CodeIgnitor’s powerful Scaffolding system to to help us build a complex, accessible form.
We are looking that the following options;
- Use PEAR’s DB_DataObject_FormBuilder.
- Build it ourselves; form gadgets and using the EZ SQL class
1) Using PEAR…
PEAR has a class to automatically build HTML form objects from a DataObject derived class. And this seems to be the way to go, and our thought (at work) was that you could use PEAR to create a HTML form based upon the database fields.
2) Build it ourselves
Using the EZSQL class we could capture the database fields and row metadata at the same time (in other classes we had to use two or even three calls to the database)…. If we built it ourselves, we’d have to build a form gadget class that would interact with the database and use a sophisticated rules engine to output valid XHTML output…
We felt it would be better to create a wizard, and feed in the table’s and their metadata; allowing the programmer to select whether a field is required, what function to validate inputted data against and whether it’s hidden. After which we could output (or write) a php file with the resulting code…
So how long would it take?
The second option would take forever and a day, and you would have to account for every possibility, every complex form gadget design… I believe the PEAR option is stronger — but both options would take a very long time to build.
By the time we came up with anything concrete; it would have been probably easier just to have built the damn form in the first place!