the problem with frameworks

I love frameworks. You love frameworks. We ALL love frameworks. As web developers we just can’t get enough of these things. They’re everywhere: from Rails, to MS MVC, to CakePHP, to Django, and so on. I’m so obssessed with frameworks that I spend more time thinking about what one to use than actually using it. But this is not the only problem, as after choosing one, your problems can really start.

On a project that I have been intermitently working on for a little while now I chose to use CakePHP. The reason for this choice? Well first, I had a pretty good knowledge of PHP as I wrote my own little PHP framework when web frameworks were a mere twingle in their daddies eyes. Second, PHP is widely supported on shared hosting – though Ruby is catching up (that said, I’ve experienced some horrors with Ruby hosting). The widespread availability of PHP also means that PHP hosting tends to be cheaper.

Anyway, this is all beside the point. My real issue is with the size and complexity of these frameworks. Just the other day I was looking to do something as simple as validate an input that was supplied as an HTML POST parameter. Pretty simple right? Well it ended up taking me a disproportionate amount of time to do this task.

The first port of call was to find out if the framework itself supported this, which to my delight CakePHP (1.2) delivered on. Now it was down to the trawl/skim through the documentation trying to figure out how to actually do it. I found what I presumed done the task – basically I was required to add the appropriate validation rules to my model. Thus I added the following:

class Section extends AppModel {
    var $name = 'Section';
    var $actsAs = array('Tree');
    var $validate = array( 'name' => array('rule' => alphaNumeric,
                                           'required' => false,
                                           'message' => 'Alpha numerics only'));

Then in my controller I simply called the validate method:

if(!$this->Section->validates()) {

What happened? NOTHING! I passed data that should have failed and it passed. SHIT! I then decided to check to see that the rules were getting parsed so changed the required key in the rules to true, and passed nothing in. Now it worked – it asked me to specify the parameter. My logic was therefore it can see the data and the rules are getting parsed so what the hell is happening!

By this point I had spent quite some time trying to figure this all out. To be honest, I could have written the validation code quicker. So that’s what I decided to do. Yes I reinvented the wheel, it took me around 5 mins, dwarfing the hours I had spent trying to get the stupid library validation code to work. Not only that, much of the supposed benefits offered by using the built in validation code was of no use to me – it wasn’t built around AJAX requests. So what is the moral of this story?

Well it’s read the documentation better, don’t run the most stupid tests, and don’t charge-in thinking you know how everything works! WHAT I hear you say?!

If only I had taken more care when reading, eh the first paragraph, in the documentation I would have observed this:

First, set the data to the model:

$this->ModelName->set( $this->data );

Whoops I never done this. Basically I wasn’t EVER passing in any data to validate, which makes my shocking test of changing the required to true to convince myself the rules and data were being parsed an absolute joke. Rushing in to write my hand crafted code is as bad as the other old chestnut of complaining “there is a bug in the compiler” – c’mon we have all said it 😉 The only thing I can credit myself with here is that after a recent 4 week holiday I was stubborn enough to not give up and go back an look at it. Therefore, if there is anything to learn from this experience it’s that before starting something make sure you have taken the time to either read the documentation or listen to those trying to guide you. Oh and have a certain amount of stubbornness about you – not too much though.