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.

being dynamic is overrated

I was going to post about a little problem that I experienced while undertaking a project I’m involved with but canned it thinking it was of limited interest. That was, however, until I made the same mistake again yesterday, so I thought I would document it to save my own sanity, even if there is no-one else who cares – not that anyone reads this anyway.

So to my faux pas, and believe it or not this cost me a few hours! The problem: well as part of my project (a bike shop website for those who really want to know – I’m programming in PHP using cakePHP. The advantages/disadvantages of PHP can be debated from dusk till dawn if that is your thing – just remember though, while you are debating all those smart people are just getting on with doing stuff. That said, my problem was, in a sense, due to the use of PHP or dynamic languages in particular.

Anyway, back on track, so the component I was working on simply uploads a set of photos and scales them accordingly. Simple as that. The problem that I kept seeing was that although the photographs were being uploaded ok, i.e no errors were being reported, I was unable to copy the files from their temporary directory over to their new home. Since no errors were being returned I was stuck as to what was happening. I battled away putting print_r’s in here there and everywhere to no avail. Then I just happened to check my call to move_uploaded_file. On inspection, I noticed I had a slight misspelling of a variable name in one of the functions arguments, thus only at that point did the variable come into existence. Therefore what was getting passed to the function was the empty string and hence move_uploaded_file could not copy the file – you would have thought it should have raised an error but no. However, as it turns out, even if it had raised an error it wouldn’t have helped me much. Why? Because straight after the call to move_uploaded_file I was doing a redirect to a new page. Therefore, any errors related to the problem http request were output to a screen which flashed by too quickly for me to notice.

So what is the root of this problem? Well if I was using a complied language it is likely that the compiler would have warned me that the variable I was passing to move_uploaded_file was either not declared or at least never been initialised. I’m pretty sure that a warning message would have been output (which I missed) by PHP’s interpreter but this is no substitute for a compile-time message. As much as I love the freedom of dynamic languages you have to be aware of this significant drawback, and people can go on about how this stuff gets picked up through thorough testing but I’m not sure that’s good enough. Also, the page redirect was a killer, as it made me miss all the output messages. It’s probably worth while not performing redirects if you find something isn’t working, just to ensure that you are seeing all the messages output by the interpreter (you can always switch it back on later). Finally, some sort of lint check should have picked this up. So from now on I think I will be running things through php –l to check that my syntax is good.

There you have it, a nice root cause analysis! I probably missed out the fact that it was my rather inane programming that was the main problem, but bugger it, I’m not really into damaging my ego.