Scott’s Technical Blog

I am using the Symfony framework for my second project major now and now consider myself proficient, if not an expert. The first project was for iChange.com and the guys on my team had enough experience that I leaned on them for the esoterica that is not included in the ‘book’. On my current project (LittleYell.com), I am working with a Symfony neophite and thus largely flying solo when it comes to figuring out the hard stuff.

For those of you in the PHP world that have never used a framework, it’s time to start. It’s not appropriate for very small projects, but as soon as you are developing a real site, it’s pointless to try to invent all of the programmatic patterns you’ll find already completed in an existing framework. By all means, check out CakePHP, Zend, CodeIgniter and all of the bazillion’s of others (http://www.phpframeworks.com/), but I recommend you use one of them rather than write yet another one of your own.

Symfony was an easy choice for my first project because I had two engineers working for me that were experienced with the framework. I talked to lots of folks (including friends at Yahoo) who were using it and did a little diligence and liked what I saw. Reading the documentation on the site was also a compelling factor in my choice. It is very well written with clear examples of how to use the framework’s elements.

When you get deeper into Symfony, you’ll find that while the ‘book’ is very clear, you’ll find it very difficult as soon as the problem you are trying to solve is not included there. The API documentation is very hard to navigate and search and very thin. Most of the time, when I’m solving a hard problem, I start by searching the web for examples, and then start looking through the Symfony code itself looking for an answer.

I would describe the Symfony code as very well written and pretty poorly documented. Had my partner Jeff and I written it, there would have been less reliance on option arrays and better leveraging of the PHP class architecture. Too many functions and classes rely on magic methods that obfuscate the underlying processes. I described it once as looking at PHP assembly language.

You can get a simple web site going with Symfony pretty quickly, but don’t expect to write a full featured, high production, website without going through the steep learning curve. Symfony is trying to solve a lot of disparate problems and thus, it is very complex.

The first project (at iChange.com) was done using Propel which was the only stable choice for a Symfony ORM at the time. Propel works great, but it has two flaws. The first is that it is VERY difficult to subclass the classes in the model. If you have a ‘user’ table with a ‘User’ class in the model and want to create a UserGuest subclass, you’ll have to go through a lot of gyrations to make it happen. The separation of Propel’s data and factory classes is at the heart of this problem.

The second problem with Propel is that complex queries are VERY hard to write. A query that takes a few minutes to test in PHPMyAdmin make take hours to code using Propel. When you get it done, it will be hard to read and understand as well.

Doctrine, which we are using on our LittleYell.com project, mostly solves these problems. You can specify subclasses of model classes when making queries and Doctrine will happily hydrate into your subclass. The DQL syntax at the heart of Doctrine is fairly easy to read and creating fairly complex queries is certainly easier than in Propel.

Doctrine is still somewhere between the leading edge and the bleeding edge as far as stability, but I’m guessing that over the next year it will be the superior ORM. I’ve had some scary problems hydrating into objects using complex queries that have crashed PHP and Apache. Doctrine really wants you to hydrate into arrays which is efficient, but not very good OO practice. I solved the problem by creating my own lightweight container objects to hold data.

I still have one query that is crashing PHP that gives me some concern. I’ve worked around it, but I’m full of anxiety waiting for it to occur somewhere else where just the right conditions for the bug to appear. I’ve done some searches on Symfony Doctrine crashes and found enough posts to make me think I’m not the only one having this problem.

An interesting note is that PHP programmers like to believe that any crash of the PHP system is the fault of the xAMP stack. Not so. It’s fairly easy to write a PHP program to crash PHP.EXE (try function x() { x(); }, for example). If you have two software programs and one crashes PHP and the other does not, folks will use the one that doesn’t.

We aren’t far enough along for me to say whether Doctrine or Propel is the better choice. We are betting on the future and better structure and picked Doctrine. You might pick differently.

In conclusion, if you are doing a PHP project that will occupy you for a few months rather than a few days, use a framework. Despite the flaws mentioned above, I like Symfony and am glad I chose to use it. Over the next few days, I’ll try to post some solutions to some of the thornier problems I’ve faced.