Symfony 1.0 Released
Symfony is an open-source PHP web framework, much in the same vein as CakePHP (which I use), and it hit 1.0 yesterday. I hopped in to take a closer look at things by poring over the documentation and comparing it to what I know about CakePHP.
Very similar yet very different
Symfony and CakePHP take very similar paths when it comes to how they approach things. It's the typical MVC approach with controllers broken up into actions. There's routes (for handling custom URLs), views, helpers, model behaviours and a bunch of other very similar items.
However, they're also quite different in a number of areas and some features might be good or bad depending on how you look at things.
Much of the configuration is handled via YAML files. Many of the features within the application can be defined and controlled via the YAML files. There's even a handy YAML reader object allowing you to build configuration files for your own application.
In CakePHP, data is passed between the client and server through a data variable. Knowing this has served me well and I've been able to conveniently pass data back and forth (like ?data[Profile][name]=Jonathan). Symfony takes a traditional approach and actually uses regular variable names (like ?name=Jonathan).
All variables used within a template can automatically be escaped for improper data. This is actually a really nice feature and one I wish CakePHP had.
Models are handled quite a bit different in Symfony than they are in CakePHP. Ultimately, all records are handled as objects (they're arrays in CakePHP). The schema is defined in a YAML file and the database tables can be built automatically using a command line syntax.
As a result of this, there are a number of base methods that are automatically created. These objects can be extended with any custom methods. In addition to the base and extended objects, there are also peer objects which are used as a querying interface to retrieve a list of objects from a particular table.
Where I think things get really complicated, is in handling selection criteria. Here's an example:
$c = new Criteria(); $c->add(AuthorPeer::FIRST_NAME, "Karl"); $c->add(AuthorPeer::LAST_NAME, "Marx", Criteria::NOT_EQUAL); $authors = AuthorPeer::doSelect($c);
As you can see, the peer object is used to define object constants and to select the content from the database with the criteria object. Pretty much all of this is a result of using Propel as the ORM wrapper.
One bonus is that i18n features are built into Symfony right from the get-go and when defining your schema, you can even define where the i18n data will be stored.
By sticking to PHP5 only, they've been able to make heavy use of the OOP features. If you need PHP4 compatibility then CakePHP is definitely the one to stick with.
Ultimately, when I look to a framework, I ask if it's going to save me time. Most of the technical choices I've made have been asking myself that question. While there's a lot of power in Symfony, I feel like much of the database handling is too complex for my needs. Handling criteria needs to be much simpler. The configuration of the application is also much more complex (but at the same time, more powerful) with frequent command line scripts. The default install recommends using Pear for installing the application itself along with any plug-ins that might be needed.
On the flip side, there's a few features from Symfony like output escaping that would be nice to have and other handy objects like response handling are already really well thought out. The built-in i18n is also a huge bonus.
Symfony isn't for the faint of heart but if you're willing to invest the time and have a flexible hosting environment with Pear and PHP5 then Symfony may just be the framework for you.
Check it out over at www.symfony-project.com.