CakePHP is THE perfect PHP framework, so we don't need anything else. Oh well, no. I personally love CakePHP, but I do believe other PHP frameworks can be interesting and maybe even useful, so today I thought I'd have a look at the Simfony Project. This framework seems to be mentioned here and there on the Net in many different ways, someone said it can do wonders, some said it's more advanced, others said something like “qcodo sucks.. cake stinks.. symfony rocks!!!!!”, so it OUGHT TO be pretty cool, definitely.

Know thy enemy someone said (OK, bad joke), so let's have a look at this interesting alternative to CakePHP. No dude, not another MVC-like, pseudo-Rails, AJAX-worshipping framework! Yes, another one. Actually Symfony is more than that: while people can say CakePHP is similar to RoR for some features and for the strong MVC architecture, Symfony chose another road. Yes, MVC is still there, but the first thing I noticed after reading their beginners' tutorial was that one of the things which Symfony seems to use quite regularly (and Cake doesn't)is code generators. Things like executing symfony propel-build-sql or even symfony propel-generate-crud frontend post Post from command line to generate your code automagically, which CakePHP – except for our little bake script – doesn't use.
See? Simfony is MUCH better and MUCH more advanced than Cake! No, hang on a minute… I just listed one thing which Symfony has more than Cake, is there any more? Yes, there is, for now: i18n – internationalization. Symfony comes with native multi-lingual support and Cake doesn't – yet – although there are rumors that i18n for Cake 2.0 is almost done. This is not speculation, re-read the sentence: First off I'm referring to Cake 2.0 (which means it will take a while) and also I read it in the Cake 2.0 ToDo List.

One of the most recurring and yet pointless critiques to CakePHP from Symfony enthusiasts is that the sites developed with CakePHP look terrible. I perfectly agree, look at this and tell me if the developer is not a complete and hopeless idiot when it comes to design and look ‘n' feel!
I do agree that some CakePHP sites (mine, mainly) don't look too good, and probably the Cake Software Foundation should pay me to put it offline. I also agree that the Symfony website looks nice and is more pleasant to the eye than CakePHP's, but I do hope that the old “design contest” doesn't get forgotten…

The Symfony team also did something truly remarkable: a comprehensive tutorial, an advent calendar, some great free source code to download and a fully functional Web 2.0-compliant online application all in one. I'm referring to Askeet, a Symfony-powered website which has been built from scratch using the framework and its development is well documented in twenty-four tutorials. In one move these guys made an interesting website, some useful documentation and self promotion… what can I say: for next Christmas we'd better chain PHPnut, gwoo, nate & the others to their chairs, close them in a small room and force them to code something like that in twenty-four days.
If I were to mention something which Symfony did well I'd certainly say the documentation. Screencasts, tutorials, advent calendars, a book, a wiki, API etc. etc. All done, and all good, I must admit that. The good news is that CakePHP is slowly catching up, and now the manual looks pretty decent.

OK, enough flattering and let's talk about something I didn't like about Symfony. I downloaded the thing and it turns out it's 1.2MB in size, a hell of a framework! After extracting the beast I had a look inside and found three directories: data, lib and bin. Not bad. I opened bin and found the three magic symfony scripts, alright; I opened data and found nine directories, I opened lib (the real deal) and found 25 directories! These guys maybe never heard of something called “an organized directory structure”, or perhaps I'm just too used to Cake's logic and essentiality.
Browsing around I found something like 247 .dat files defining country names and currencies in all the languages of the world, script.aculo.us and prototype libraries, javascript calendars and other wonders… Weeeeheee!
The good thing is that Symfony seems to include pretty much everything you'd ever need, the bad thing is that personally I will never use any of the thirteen Chinese-related .dat files in th i18n directory. This philosophy is exactly the opposite to Cake: at first i got pissed off when I noticed that CakePHP doesn't include prototype by default, but then I realized that if they started include everything you might need someday we'd end up like… like Symfony, with 1.2MB of stuff 500KB of which – at least – will most likely not be of any use for the average developers.

The other dangerous consequence of including more and more stuff is the so called widget-temptation: If you include script.aculo.us you MUST show off and offer some weird toy someone may use… well, Symfony seems to go in that direction, and someone compared it to component-driven frameworks like eZ Publish rather than more general-purposes projects. I'm sure the admin generator can be damn handy, but what happens if I'm a terribly annoying guy who'd like to tweak it and change it so that it fits my needs? In Cake… well, there's nothing “official” included in the core, and when you find a third-party helper or component you feel you can take a look and poke around, extend it, or change it totally. It's all up to the developers and their needs: personally think that widgets are useful, but some times people like a bit more flexibility.

So the overall impression of Symfony is that – regardless its arguable, self-proclaimed, enterprise-ready status – it is rather complex, with a steep(er) learning scheme which doesn't justify the extra features.

From the My first Symfony project tutorial:

So, the weblog will handle posts, and you will enable comments on them. Edit the file sf_sandbox/config/schema.xml and paste the following configuration:

<?xml version="1.0" encoding="UTF-8"?>
<database name="propel" defaultIdMethod="native" noxsd="true">
  <table name="weblog_post" phpName="Post">
    <column name="id" type="integer" required="true" primaryKey="true" autoIncrement="true" />
    <column name="title" type="varchar" size="255" />
    <column name="excerpt" type="longvarchar" />
    <column name="body" type="longvarchar" />
    <column name="created_at" type="timestamp" /></p>
</blockquote>
</table>

<table name="weblog_comment" phpName="Comment">
<column name="id" type="integer" required="true" primaryKey="true" autoIncrement="true" />
<column name="post_id" type="integer" required="true" />
<foreign-key foreignTable="weblog_post">
<reference local="post_id" foreign="id"/>
</foreign-key>
<column name="author" type="varchar" size="255" />
<column name="email" type="varchar" size="255" />
<column name="body" type="longvarchar" />
<column name="created_at" type="timestamp" />
</table>
</database>
<p>

This code is longer to read than to explain: It describes two tables Post and Comment.

NO! Sorry, no. This is NOT simple. It is logic, clear and makes perfect sense, it's not that I'm retarded and I can't write or read XML files, it's just unnecessary. You create this and then call the slave-script to create the model and the corresponding database table… This is exactly the enterprise way of doing things CakePHP made me forget. Convention over configuration. Not hundreds of configuration files.

But there's more: you can even configure your views with some simple .yml (!) file:

default:
  http_metas:
    content-type: text/html; charset=utf-8
  metas:
    title:        The best weblog ever
    robots:       index, follow
    description:  symfony project
    keywords:     symfony, project
    language:     en

Sure, it's good. It helps, and it's certainly useful, but I'd rather code a custom component to do the same thing with a few arrays. Again, this is arguable.
Validation is done through .yml files, and you can configure your administrator backend through a .yml file too! Cake has .ini-based ACL, and that's about it: if I don't want to use them I don't use them.
Clearly you probably don't have to edit all settings in the configuration files, but I just don't like the approach, personally.

Oddly enough, Symfony's slogan seems to be “professional web tools for lazy folks”…

It all depends on what you need. For my needs I chose CakePHP, and here's why.