Michiel . van Vlaardingen

My previous post was a bit generic, but now I’ve encountered the perfect example of how building a Framework slows you down:

Lets say we are building basic user account confirmation. In a plain-php way I would write:
mail($email, “Your account confirmation”, “….”);

Now in our framework it has evolved to something like:
mail($email,  $settings->getSetting(CONFIRMATION_MAIL_TITLE), “…”);
and the actual text is loaded from the settings table in the database (so our non-tech partners can edit as well).  So all is now configurable and nice and quick and smart right?

NO, because in a new project, the database is clean, so I get a nice “confirmation.mail.title setting is not defined”.    And now this is where I slow myself down:  Instead of just adding this entry to the database I think:  hey, I shouldn’t get this error, this should have a default setting.   So now instead of having to write this one simple line of code I have to:
– find a way to store all default settings in some file in the framework distribution
– adjust the settings mechanism to use those defaults if there is nothing in the DB
– retrieve all data in the settings table from a previous project and store it in the file

And as soon as I have this thought cross my mind, the focus on the original project is gone and we are back at the infinite task of the perfect framework.