PHP as Framework

Revising a CV (or if you'd rather, a résumé) is generally seen as one of the great irritations of leaving one role and seeking another. But it also gives you the chance to look back and see not only what you've achieved over the last few years, but what's changed in the industry you work in. For PHP developers, the last three years have been particularly interesting. Thanks to the development of composer, the maturation of a second generation of high-quality frameworks, and the work of the PHP Framework Interoperability Group, we now have a feast of high-quality, interoperable components available to us, with a trivially easy installation process.

To my mind, that means that we can change how we look at the idea of a "framework" in PHP. The definition has always been pretty loose, but let's think of it as "a set of software components, designed to work together, from which we can pick and choose the functionality we need". That used to mean selecting a framework or CMS like Zend Framework, Symfony or Drupal, downloading an archive and picking the bits we needed of it, usually with a maze of require statements. Extending behaviour meant searching down third-party libraries, downloading and incorporating those, and hoping that the versions of the various libraries you happened to have played nicely together. This wasn't always particularly easy, reliable or enjoyable, and so it was often considered easier to write the required functionality in-house. And we've all spent more years than we want to think about in maintaining that type of application than we really want to think about.

Now, though, a number of inventions and initiatives have come along that give us an alternative. Distributed version-control systems such as Git and Mercurial, and broadly-available, trusted DVCS hosting providers such as Bitbucket and Github, mean we have a standard way of making source code available to end-users. These also give us a standard mechanism for collaboration and contribution of code via wikis, issue trackers and pull requests. Composer and Packagist give us a common vocabulary and resource locator for specifying dependencies and versions according to semantic versioning rules. Together, this means that we can specify our top-level requirements in a composer.json file, sit back and let composer serve us up our own custom codeset.

Of course, while all PHP code can be interoperable, some code is more interoperable than others. However this too has improved over the last few years, through two main mechanisms. The first is the emergence of widely used and reliable libraries and frameworks like as Symfony2 and Doctrine, which now underpin a wide range of projects, providing an implicit compatibility. The second is the work of the PHP Framework Interoperability Group to make compatibility explicit. So far they've normalised autoloading, code standards and logging, and look to be in the process of defining standards for documentation, caching and HTTP request and response access. Collectively, these mechanisms help extend the "Pick and Choose" mentality of a framework across the whole of the PHP ecosystem, and break down the silos that separate different named projects and frameworks.

To make the best of this, however, we also need to stop putting ourselves, and other developers, into silos. Companies and agents advertise for "Drupal Developers", "Symfony Developers" or "Zend Developers", and I'm not sure that either they nor I understand what those terms mean. These projects are all a combination of MVC framework and library; the model should be a matter of the company's own business logic, the view's usually based on either Smarty or Twig, the persistence layers tend to be fairly standardised, and the controller should really be lightweight and keep itself out of the way. If the libraries are well designed and interoperable, then the only things that should be specific to the framework in use should be configuration and routing (or hook mechanism). Once the project has passed its inception phase, the time or expertise needed for either of these mechanisms should be minimal, and we should be looking not for "framework specialists" but once more for "PHP developers".

It's for this reason that this site doesn't use a heavyweight framework such as Symfony2 - although it does have the flexibility to use all of the Symfony and Sension components. Adze, a minor extension to the lightweight Silex microframework, needs only minimal setup to give me a caching Twig-based View layer, a very lightweight Controller, and an adaptable persistence layer via Doctrine DBAL that let me quickly use tools from the entire PHP ecosystem to build whichever custom models I need, in much the same way I'd build them into any larger framework or project. And the flipside of the flexibility afforded by the new interoperability is that I, or anyone, can easily share this code for others to use via my github page and for installation via composer. It may be simple as yet, but by developing it in the public eye and with a mind to wider use, if it does grow, it'll grow in the most useful way possible.
Posted by parsingphase, 2014-09-17 16:15

Anonymous user



Contact Richard