Question

All the popular PHP frameworks today use their own view layer implementation that is based on pure PHP templates and lots of helpers. I’ve tried some of them and always found that this approach introduced huge complications to quite simple things. For example, in Zend Framework forms and the pagination use their own solutions to customize the look of these items. The helpers re-invent loops, providing also quite slow solutions, and the whole view layer, in my opinion does not exist as a one part, but many of its functionality is delegated to other parts of the script. The same configuration problems occured in Symfony and admin generator, and in Kohana I was forced to duplicate the same code over all my forms. Is PHP really a good choice for the view layer? Do you also find these implementations inconvenient or maybe, why despite all these problems they are good and cannot be replaced, for example by a smart template engine (I don’t mean Smarty :))?

Answer 1

Now I like PHP but ultimately, first and foremost, it is a templating language, not a general purpose programming language nor an object-oriented language. Don’t fight it. Embrace it.

I’ve looked at a few different MVC frameworks like Symfony, CakePHP and Zend and I have a hard time getting past the examples. Typically they are ‘with these 17 files you can make a ‘Hello world’ program!’ Huh?!?!

There is such a thing as complexity for sake of it and solving a problem before you have a problem and I’m yet to be convinced that these heavyweight (they are heavyweight) frameworks really adds value.

I’m more of a fan of the ‘no framework’ framework. This is really ‘roll your own’ but I think that it leads to the leanest, cleanest end result.

I feel similarly about Smarty. A lot of people on SO are big fans of Smarty but it’s never made sense to me why you’d add a templating language to your… templating language.

Ultimately I end up writing this kind of PHP script most of the time

<? require 'config.h'; // set up constants, DB connections and so on page_header('My Page'); // page header, site menu and so on deny_unregistered(); // security if (/* user submitted page */) {   $valid = validate_form(/* validation rules */);   if ($valid === true) {     // do db changes     // redirect user ie POST+REDIRECT+GET   } else {     // output error messages   } } ?> // display page <? page_footer(); ?> 

With judicious use of helper functions (eg pagination links), the above is incredibly easy to read and debug. I also much prefer it to this model:

URL: /index.php?inc=blah

index.php:

<? require '$inc.php'; // hopefully you sanitize this but so many don't ?> 

I find this ugly, error-prone and even dangerous. I have a hierarchy of PHP files that mirrors the site structure (from a menu point of view) where each page is a PHP script. If they have common behaviour they both require it (not require_once, which is typically used as a hack for poor organisation).

Simple, easy, understandable, straightforward.

It seems a lot of programmers will throw a framework into the mix before there is really ever any need. I think this is a fairly lazy practice and one with a big cost: every decision made today is one that becomes harder to change later so put off making decisions like this as long as possible. Introducing something later is easier than introducing something now, finding out it doesn’t really do what you want and then changing it later.