News Archive
PhpRiot Newsletter
Your Email Address:

More information

Symfony2 stuff

Note: This article was originally published at Planet PHP on 31 October 2010.
Planet PHP

Since about 4 weeks I have really started using Symfony2, in development for a work project no less. Kinda crazy seeing its still in pre-alpha phase, but I think its a great platform today and I know its going to be the best soon aka once we have a stable release. But in these 4 weeks quite a few things have popped up that I like to see addressed. Most things aren't really about writing code, but figuring out how things should be. The kind of stuff that is hard to fix on your own. At the same time there are not yet that many people to collaborate with, so I think I will have to accept that not all things will get an answer right here, right now. Also a lot of it is pondering best practices, aka documentation. To keep an overview I figured I should make a little list, since right now I just have a ton of flagged emails. Also I might entice some people to follow up on stuff on my list at the same time.

1. Making 3rd party controllers truly reusable

This is what I last blogged about. Since then a couple of things have been fixed and I think we are starting to figure out a good solution for the last. The main issue I see left is that a direct mapping of a service name in a controller to a single service doesn't quite do the trick. For example if a controller is supposed to generate output for a specific format I need to potentially replace the default "templating" and "response" services. But if that some controller is supposed to handle multiple output formats things will get tricky. I either have to create a "templating" and "response" service implementation that can do them all, or I need to have a meta service that then makes instances of the right one dynamically. It gets messy and the risk is great that everybody will come up with their own approach. The current idea to solve this is by making it possible to switch the actual service for the DIC to load based on a "context" which can be defined inside the route (and I guess also the constructor of a controller).

2. Flash message handling

Here I am still fairly lost what the best approach would be. Basically I don't really like that flash messages seem to be set inside the controller. Also if they are set there, I think they should not really contain normal text, but more a "key". But I guess this is the same for all translations. The good news is that this is supported by the Symfony2 translation system, aka the keys used in the translation system do not need to represent a "real" language translation. That being said flash messages may at times also need parameters, which makes it a bit tricky to separate the setting of the flash message and the actual use of the flash message inside a template. Finally right now it seems many Bundle's include outputting flash messages inside specific templates, but I actually think that in many cases you would want to output flash messages in a fixed location inside the layout template.

3. Easy DIC customization of 3rd party Bundles

Another thing I am still fuzzy on. I noticed that the DoctrineBundle does a lot of work inside the Extension class to setup the DIC configuration. This makes it quite tedious to extend. For example I was pondering adding a "beginTransaction()" call after creating the DBAL connection inside my functional tests, so that I would not have to clean the database after each test. But the way things are now I cannot do this in XML or YAML. I actually have to extend the Extension class itself, which doesn't seem right.

4. Issues with setting GET parameters in functional tests as well as forward() calls

I tried debugging this issue with, but it doesn't allow inspection of nested objects so I never got anywhere. The issue is that when I do something like the following the GET parameter gets parsed but lost somewhere along the lines:

= $this-createClient(array('environment' = 'test'));

Truncated by Planet PHP, read more at the original (another 4905 bytes)