New Symfony Nerds Blogger! SymfonyNerds would like to welcome Lawrence to the team. Lawerence will be contributing to SymfonyNerds with updates from the world of Symfony. Here is his first blog below. If you are interested in contributing to SymfonyNerds, let one of us know!

My name is Lawrence. I am honored to be able to contribute to SymfonyNerds (my own blog is over here). I am mostly going to be contributing link round-ups, pointing to stories about Symfony that I find interesting.

First up, Doctrine is now the default ORM for Symfony (or rather, it will be starting in version 1.3):

Doctrine is now the default ORM for symfony. We still support Propel, of course, but recommend you start new projects with Doctrine.

I guess this news was expected for a long while (Jonathan Wage is the lead programmer on Doctrine, and he is also one of the core Symfony team), but now it is official.

One of the worst things about the Zend Framework is the way the caching is set up. You have to clear the cache after every change that you make. Symfony partially escapes that - using a dev front controller, you can see some of your changes, but you still need to run “symfony cc” when you change a Yaml file or add a new class that needs to be auto-loaded. Thankfully, that changes in 1.3:

A new autoloader has been added to the development environment that knows when changes are made, so you no longer have to run symfony cc after adding a new class.

It also sounds like a lot of the performance improvements that had originally been discussed for Symfony 2.0 are instead showing up in 1.3:

When we queried the community for feedback on what we should work on for symfony 1.3, performance was at the top of this list. We’ve taken this feedback to heart and have made significant improvements. A large portion of the routing system was rewritten to facilitate matching the incoming URL to a route much faster.

This is important. A competing framework ran some tests, according to which Symfony ranked as the absolute slowest. Speed is one issue where Symfony defitely needs to improve. (Noupe offers a balanced review of the most popular PHP frameworks, and says “[Symfony's] main downfall is that it is a bit slower than other frameworks.”

Ryan of That’s Quality is now working with Symfony on the Amazon Cloud and he says it is awesome:

As explained in part 1 of this series, the server you’ve instantiated acts as a static entity. Yes you can make all of the changes and customizations you want to it just like any other server. However, as soon as you shutdown that instance, all of those changes are lost forever. The solution is to save your server setup as an image (called an Amazon Machine Image or AMI), which can then be used later to instantiate new instances. This actualy forces you into the very responsible habit of always having an image of your exact server setup. From here you can very easily restart your instance or launch several identical servers and load balance between them.

I actually have my doubts about the Amazon Cloud. I’ve looked at Mosso and SliceHost and MediaTemple and they all seem simpler than Amazon’s Cloud. They offer virtual servers that feel like real servers, whereas Amazon’s services make you deal with the reality that there is nothing real about the offering. Possiby, as Ryan says, this forces good habits, but it is a pain to get started with. (And then there is the question of cost. My friend Chris Clarke jokes “Cloud computing is the future of hosting because the hosting companies are not making enough money off of standard hosting.” I rent a dedicated server from Hostway for just $99 a month, whereas Amazon’s basic setup is about $80 a month. So I would save $20 a month if I switch? Maybe. But I think my machine from Hostway has more capacity than the basic LAMP AMI I worked with this summer. Ryan mentions cost at the end of his article: “Above all else, clouds a hella-fun but expensive unless you really need to flex something.”)

Moving on to a different subject: I’ve been working on a site that allows for users to upload files and hold them privately, or share them. The files, of course, need to be stored out of the document root. I found this article by Timo Haberkern of Symfony Zone very helpful:

As we now use a Symfony-Controller you can do just use the complete Symfony infrastructure. You like to secure the PDF-files? Just enable the Symfony security mechanisms (is_secure: on in the security.yml) and only logged in users can download them. In the same way you can create paid content.

Finally, there was a conversation about memory usage and Symfony, over on the Symfony User Group, and Gareth McCumskey had this interesting remark:

One way to reduce your memory footprint is in the Propel criteria you use and the data returned. Propel’s hydration of returned data into objects can be quite high. We have actually used the Propel method doSelectRS (doSelectStmt in Propel 1.3) and selectively chosen which fields the query should return as well as then iterating through the result set ourselves and adding them to an array instead of having fully hydrated objects which can be memory hogs.

For small queries where the number of results returned is always going to be small, doSelect as is is great, but for large, unwieldy datasets its a better idea to use doSelectRS/doSelectStmt and then manage the results yourself.