Once again out comes the felt trimmed fedora as I take a look at another PHP framework in my on going review to find a web framework that best suits my needs. Today I’m testing out Symfony.
First off it should be noted that Symfony is a PHP5 only framework. For some this may not be a problem, but for those looking to host their site on the majority of web hosts around this could cause problems. Now I’m lucky in that the servers I’ll be looking to host on will either be run by myself or have PHP5 as an option. Support for PHP4 is set to be discontinued, at the end of this year there will be no more releases, and critical security updates will only be available until August next year. According to some PHP5 only accounts for 22% of the of generally available versions of PHP on web hosts. So if you’re looking for a PHP framework you really should consider you’re hosting options before looking at Symfony PHP. Personally I welcome the change to PHP5, the OO style is much improved over PHP4 and I’m hoping that this will at least give web admins a good excuse to make sure set up sensible configuration options, I mean if you’re going to break compatibility with old scripts you might as well do it in a worth while cause.
Anyway Symfony is another framework that for the most part glues together what it considers the best PHP libraries around for the tasks it needs. Pake and Phing for project build/management, Propel for ORM, Creole for the database abstract and homegrown Lime for unit testing.
Installation
Again installing was easy, Symfony was available via apt/fink (got to love package management tools). Those without one or who prefer to install the latest and greatest Symfony is also available via PEAR. For Perl people this is something akin to CPAN, and those Slytherins amongst us I guess easy_install/setuptools would be the closest analogy. Those installing by hand will want to make sure that they have the required libraries mentioned above installed.
Documentation
The documentation is good, like some other frameworks they are developing a Symfony book, API as well as a general documentation on the framework. Not to mention a snippets library, wiki and forums for you to ask your questions. For some reason, although I found the documentation itself good I find the index a little confusing, it seems to be more of a small keyword index rather a more descriptive index.
As for howto documentation there is the basic blog done in symfony, the more complex askeet in 24 days/hour and a host of community how tos as well. I should note that I was going to look at symfony first, but a month a go when I first looked at the askeet tutorial there seemed to be a problem with the website that prevented me from getting past the first day, but that seems to be fixed now. Going with the “official” how tos I plumbed for the basic blog, but if you fancy something a bit more in depth the askeet is excellent, not only covering Symonfy but also takes you through the basics of working with SVN while developing.
The basic blog tutorial only covers one page, and while the result doesn’t look that great it does give you enough of a run through creating database/models/controllers/views etc. This tutorial expects you to download a pre-created skeleton project, but if like me you create the project from scratch using the symfony command line application then you’ll need to make sure you configure you’re database correctly. For me this just meant editing the propel.ini/database.yml to point to you’re database correctly.
Which brings me on to another point. Symfony configuration is done through a file format called yml, those not familiar with this shouldn’t worry as it’s a very simple format and the documentation covers exactly what these different configuration files expect. The only downside I saw from the configuration was that in order to specify your database you have to edit both database.yml and propel.ini so you’re project knows where the database is and also that command line tools that uses propel knows where you’re database is. This is a minor point as you probably won’t be changing your database that much, but it would be nice if these could be integrated some how.
Another minor point regarding documentation is that propel, the library for automatically generating your database/model can be done via both yml and XML. The basic tutorial takes the yml approach and the askeet tutorial goes down the XML route, not a big problem but I’d like to symfony take a stand on one or the other if at least for consistence in the tutorials, even thou it’s good that it allows both types of configuration formats to be used in production.
Other than that I found the tutorials of excellent quality, the framework seems to allow you to provide the minimal details required to get up and running while allowing you to override these things later on. Controller function is done via named convention, or more correctly a controller function name needs to be prefixed with execute e.g. executeIndex, executeUpdate, etc. Models are provides via a super class convention, when you create models via the command line from your database it create Peer classes which your actual model classes subclass. So if at a later date you need to recreate your models you can do so with no or minimal changes to your actual class files. While models are specific to your project, like Django, Symfony allows you to create multiple apps in each project. Each app can access the same model but you can create different controller/views for these apps.
A little spit and polish
Symfony provides all you expect from a framework, automatic creation of database/models, ORM, unit testing, batch control the works. The automatic creation of models,controllers even scaffolding/admin views allows you to get up an running quickly with minimal configuration, while the configuration possibility coupled with the clever class systems of models allows you to expand this should you need.
I have to say I’m impressed with Symfony it seems to provide it all but I doubt it would be too easier to change the ORM library should you need but those preferring Smarty over PHP for the templating should take a look at the sfSmartyViewPlugin. Now Symfony has hit the big 1.0 the API should be stable and the documentation is top quality generally. My only real complaints are that parts of the documentation could do with a little polishing to round off those confusing corners, but those are minor complaints.
So if you can get past the fact that is a PHP framework (this is hard I know) and you know that you’ll be running it on a web host that supports PHP 5 then Symfony is worth a look.
Addendum
How could I forget two of the most important things that really turned my head while using Symfony?
Firstly the symfony commands “freeze”/”unfreeze”. When developing a project using the command “symfony freeze”, will copy over all the libraries that symfony uses to you project directroy, so when you upload it to your production server you know that it will be using the version of the libraries that you developed it in (unless a conflict crops up of course). Similarly unfreeze will remove those libraries from the project directory so you can test with updated libraries before “freezing” again and re-uploading to your production server!
Secondly, and possibly more importantly for developing, Symfony provides a web debugging interface. O.k. debugging might be the wrong word, take a look at this;
.
Did I mention that when Symfony creates a app for your project it automatically creates a production/development environment for you to work with? No? Sorry, well it does. So when you’re working within the dev environment you’ll get this special toolbar which gives you information about the process that Symfony went through to create the web page you’re looking at. So you enter a URL and you don’t get the display you’re looking for? Take a look at the stack trace and hopefully you should be able to see where you’ve been going wrong. Not to mention that it also gives the the execution time and also the number of database querys (including the execution time for each).
If other frameworks are looking at improving their debugging method I’d really recommend taking a look at Symfony’s style as I can imagine it was/will be enormously useful in the future if I use this framework.