Symfony PHP Framework: part 2

In a previous article I spoke about my first impressions of the Symfony PHP framework. This article follows up with my thoughts after having used Symfony for a few weeks.

When I first started working with Symfony I noticed I wasn't doing a lot of programming. Rather, I was editing configuration files and using the Symfony command line tool to auto-generate modules. This might seem like a dream to some developers, but I like programming so I was disappointed. Fortunately, once you start having to customize your project to a greater degree, you do still need to do a fair amount of programming, depending largely on the nature of the project. Now that I'm used to Symfony, I'm enjoying the programming even more as everything is very structured and logical.

One nice feature (that is really a feature of PHP 5), is class autoloading. This means that classes that I place in specific places can be instantiated or called statically without me needing to include or require them from another source file. So, for instance, I have a class "UrlHelper.php" in the lib/util folder, and this is available from every other part of the application, including the templates.

One of the most impressive features of Symfony is its ability to generate backend modules using the admin generator. As an example of what this is, imagine you have a table in the database, "car", where you store a different model of car per record. Using Symfony's command line tool, you generate a module to list, create, edit & delete records from the car table. The admin generator does not actually create source code which you can modify (as it inherits from pre-existing classes in the framework), but you're not stuck with the default set up as the module is highly configurable. Also, you can override things like the default templates with your own.

Symfony comes with features that make dealing with forms easier, once you learn a few rules. My favourite forms feature is the fillin directive, which can be set in a configuration file to enable a form to be repopulated if it needs to be redisplayed. With one configuration line you can ignore the cumbersome task of repopulating the form manually with statements embedded in the form's HTML.

Search engine friendly URLs in a Symfony project can be achieved with the routing system. This again uses YAML configuration files and is surprisingly simple yet powerful. For example, it is easy to route a request for /articles/php5_released.html to the module article and the action display, with the parameter article_name set to "php5_released". With such a routing rule set up, the complimenting logic to format links is automatically used, such that using a link helper to display a link to "article/display?article_name=php5_released" (where the first component before the "/" is the module, the next is the action, and the parameter follows the "?" as with standard HTML links) would yield the path "/articles/php5_released.html".

A small drawback with Symfony, in my opinion, is how page titles are set (as in the value of the <title> tag). They can be set per page in a configuration file called view.yml. Unfortunately, this file is one of the few where previously defined constants cannot be used. For example, if you wanted to append every title on your site with " - sitename.com", where the site name was a variable, you wouldn't be able to do that using the view.yml files, since they would require a literal value. Still, I was able to use a filter to achieve the same effect by manipulating the rendered page before it gets sent to the browser. Another solution would be to set the title in the action or template itself (which I do use for dynamic titles on database driven pages), but the filter solution seemed elegant for the particular issue at hand, that is, adding the same suffix or prefix to all page titles.

I plan on updating this article with some more info soon, so do come back!