We need to develop fastly, reliably, and with a minimum number of dirty hacks. Thanks to Symfony we have achieved great things so far. But now is the moment for us to move forward.

We’ll give a few recent examples of things we can’t simply ignore anymore. Sometime, these limitations are surely due to PHP more than Symfony but hey, Symfony is PHP based – for the good and the worse and therefor inherits some of its problems.

1. Propel has behaviours. Great, sounds good; then you see the amount of code you have to inject into your classes to make it work (see example above). Ok not that great but still usable and it’s a PHP limitation here, it couldn’t be done differently anyway. But wait, it also prevents me to use __call() in this class as well ? Not good at all, not flexible enough…

2. Yaml support. Could Symfony support _all_ the features of the language please ?

3. Template caching: ok but not so great. Symfony has template caching for actions, partials and actions + layout (the page is then fully cached). But actually, caching is just half of the problem. Now the question is how can I expire _one_ item of the cache manually ? Short answer: you can’t. Longer answer: you can, but it hurts _a_lot_.
Looks like GIT vs SVN. You can branch easily but then you may struggle when it’s time to merge your changes back to the trunk.

4. Admin generator. Do you guys really thinks it’s the way to go ? Are you really really sure ? Think harder because it’s waaaay too complex to be interesting. Not when you use them, but when you have to modify them (which may or may not happen depending in your requirements).

5. Migrations please. (I know it’s already been said but it’ll really help everyone).

I could continue all the day like that. We’re switching to Rails in 6 months. It’s all planned and budgeted. Thank you Symfony it’s been a pleasure to work on this framework. PHP go to hell.

BTW, there *is* a symfony console of sorts.
http://code.google.com/p/symfony-interactive-shell/

So you can run a “console” similar to irb – Ive used it to do stuff like this:

>> $c = new Criteria();      

>> $c->add(ArticlePeer::ID, 8);

>> $articlet = ArticlePeer::doSelect($c, null);

>> print $article;
Array
(
)
>> print ($article[0]->getTitle());
Buying a Home

Ive been very interested in Rails since 2004 (I host nycruby.org and help organize the meetings of my local Ruby group), but my day-job is PHP/symfony so I dont get to play with Rails as much as Id like. Also, to get the best out of Rails, you really need to learn Ruby so you’re basically learning two things at the same time – not always easy especially if you dont have a lot of time to devote to them. But Im playing with Capistrano to deploy symfony apps

Im hoping that future symfony releases will take the best ideas from both Rails and Django (a lot of indications seem to show that this is happening). I too was very enthusiastic about Rails and Ive no doubt in my mind that it has brought a lot of good ideas and best practices to web development in general. But my enthusiasm did make my gloss over some of the things I didn’t like. So I guess all Im saying is that’s there’s no perfect framework, Rails and symfony are both good within their ‘languages’ communities.

symfony sync production go

Which just does an rsync from your copy to the remote server. It doesn’t go through source control, it can’t go to multiple backend servers in one go, it can’t upgrade database structure afterwards. There is so much more that Rails deployment/Capistrano can do.”

One thing to note is that Capistrano is not Rails specific / only, especially with the release of Capistrano 2. My team currently uses Capistrano to automate the deployment of our Symfony applications.