In this recent post to her blog Lineke Kerckhoffs-Willems talks about some recent Symfony2 development she's been doing and some of the trials she's come across when trying to implement the SonataAdminBundle to build on their pre-existing Doctrine2 entities.

I have been doing a lot of Symfony2 development lately for our project ProTalk and one of the things we needed was a backend for our database. This should be a fairly simple backend to start with, just an easy way to get data into the database. So I thought I would use the SonataAdminBundle to easy generate this backend based on the doctrine2 entities that we already have. Eventually, I got it working, but it took me some time to find out exactly how, so I thought I'd share my experiences.

Based on some information she found in this other post, she was able to configure and connect it to a "tag" entity. To make it work, however, she needed an empty controller to move forward.

Lukas Smith is looking for feedback about a question that's been in his mind a lot lately - can the handling of query parameters be made better for the Symfony2 framework (and even easier to use).

Obviously you can already access query parameters today already but it could be easier. Essentially what I want is a way for developers to easily configure what query parameters they expect and what values they expect. This is useful for several things like easier reading and validating of query parameters, self documenting API both for API docs for humans but also for machines.

He's asking for feedback and ideas from the community on a proposed solution that could make things more flexible. He also briefly mentions the route matching and how qurey parameters could cause them not to match:

For one I don't think that a mismatch on a route requirement of a query parameter cause the route to not match. However then it can quickly become confusing for the end user or it would require adding more and more syntax to handle all the different cases.

In his previous post Sebastian Göttschkes introduced a set of classes you could use for different types of testing in your Symfony2 applications. In his most recent post he expands on these examples, giving the UnitTestClass an extra ability.

In one of my last articles on Testclasses for symfony2 I explained some of the classes I use for my tests. Since then I found a great article on metatesting and want to update my UnitTest class to show some practical examples.

His update allows the class to access private properties via a "getAttribute" method that, via PHP's Reflection, allows you to pull out the private property's value and a "setAttribute" that lets you inject a value back in. He includes a word of warning, though - if you're using something like this often., you're probably "doing it wrong" and might need to think through your application design a bit more.

You can find the source for his classes in his previous post.

The ServerGrove blog has a recent post for the Symfony2 users out there, showing how you can spool emails on a VPS/shared hosting using SwiftMailer and the Symfony2 bundle to interact with it.

When you send an email, the mailer communicates with a remote server in charge of receiving the message and of delivering it to the recipient. This process can cause your form to submit slowly as it depends on how fast the mail server responds. Spooling allows us to decouple the application execution line from the process of the sending one, two, or as many emails as we need.

They show you how to configure the SwiftMailerBundle with the mail server's settings, how to set up the command to send the emails and the settings you'll need to put in your cron file to run the "send" operation periodically.

In this new post Wojciech Sznapka shows you how to can set up an Apache Ant deployment for a basic Symfony2 application - including installation of vendor packages and assets.

When you have plenty of Symfony2 applications and you need to deploy them from time to time, you are probably sick of thinking about every activity you need to do for every deploy. Often people use some build scripts, which are hard to maintain and tends to be unreadable. I wanted to automate it as much as it possible and I've choosen Ant, to help me out.

An example build.xml file is included in the post that shows how to:

• Pull the current code from git
• Install vendor packages
• Fix permissions for the log and cache directories
• Clean up the cache
• Dump/install any additional assets

In this new post from the ServerGrove blog Ismael Ambrosi shows how to create a "cache warmer" for a Symfony2 application - a handy tool that can pre-populate your applications cache with data you specify before it's needed by the app.

The cache is a very important part of your Symfony application as it helps your web server to perform better by not executing unnecessary code on every request, this is especially true if your server is running with limited resources. Cache warming allows you to cache specific data in your application through the use of a CacheWarmer. Symfony 2 includes a cache warmer that helps you to store parts of your application in cache, before the application becomes available to the user.

He shows how to create the "warmup" in an object extending the CacheWarmer to pull in content (in his case, just a text string) and write it out to a cache file automatically. Also included is the config updates you'll need to make to tell the Service Container about the Warmer.

Rafael Dohms has a new post sharing the results of one of his recent struggles - getting a Symfony2 application deployed to the PagodaBox service using Composer to manage the packages. In the post he details each step of the process.

I have been working on a little pet project and wanted to put it up somewhere to show to a few people how it was going. I wanted something really simple so I decided to give the PHP PaaS solutions a try. Its a very simple Symfony 2.1 based app using Composer for vendor management, so I went on a quest to see what could be done and how.

He shares the contents of his Boxfile (a special file PagodaBox uses to configure your application) with entries for writeable directories, extensions to load and the database configuration. He found that, during deployment, everything is writeable by the "build" user, so there's no worries about installing Composer dependencies.

In this recent post Sebastian Göttschkes shows how to use the vfsStream stream wrapper in a Symfony2 application to create tests that involve the local file system.

I read about vsfstream when skipping through the phpunit docs. Back then, I decided I don't need a virtual file system. Some time later, I had to test classes which read and write files and found myself creating and deleting temporary folders, messing around with nasty errors (like my favourite one where for some reasons tests fail when I don't use @runTestsInSeparateProcesses).

He walks you through the install process, how to register it in the Symfony2 autoloader (so you don't have to include the files each time) and how to include it (via namespace-based loading) in your tests.

In this latest post to his blog Stefan Koopmanschap shares a quick tip about using the git-svn tool with the dependency installer in a Symfony2-based application.

I work a lot with Symfony2's deps file for installing 3rd party bundles into my project (yeah I know, I should be using Composer, right?). This works really well when working with pure Git. However, when you're not using Git on it's own but instead use git-svn, you may run into some issues when issuing git svn dcommit,

One issue relates to a "Failed to read object" error that could come up during the push. His solution involves a few steps (manual ones) to prepare those bundle directories and make it easier to push the rest of your changes. He also includes a few links to other resources that he found around the same topic.

Hari K T has a new post to his blog that shares his concern about a "design flaw" in the component/package methods promoted by Symfony2 and Zend Framework 2:

Looking from outside both Symfony2 and ZF2 is full of standalone components. But the reality is not the same. Though Symfony2 components are split into each components in github, you cannot give a pull request to that component. The tests for all the components still resides in the core.

He points to the Aura framework project as a good example of how to make a truly component-centric set of tools complete with tests bundled into the component's download right next to the source.