Symfony2: Getting easier

With the release of the first beta approaching fast, our main focus has switched from adding new features to polishing existing ones.

Symfony2 has many great features. But sometimes, configuration feels a bit too complex, or the error messages are not friendly enough. We care a lot about these problems as these issues can lead to a lot of frustration.

Recently, Ryan and I have spent our time tweaking error messages, simplifying the code and the configuration, adding more documentation, and making things more consistent throughout the framework. The goal is to ease the learning curve and make things that people will need on a day to day basis simpler.

Let's see some examples of what we've done so far.

Better Twig Error Messages

Twig is a great time saver thanks to its concise syntax and its great automatic output escaping feature. Each time I need to edit an "old" template written in PHP, I'm really happy that this is just about legacy code (and apparently I'm not the only one)

One problem you might have encounter though is when something goes wrong during template compilation or at runtime. Sometimes, the exception message does not mention the original template name, nor the line where the problem happened; and of course, the PHP stack trace only has information about the cached PHP file. That makes debugging harder than it has to be. This has been "fixed" recently. Now, Twig tries very hard to always tell you where the error occurred in the original template file.

And on a totally unrelated note, Twig now also enjoys native support in PHPStorm.

Better Configuration Error Messages

What I've described above also apply to configuration errors. Here, we are talking about configuration files (in XML or YAML) instead of Twig templates. For instance, if you use a non-defined parameter in a service definition, you will have the following error message:

The service "%s" has a dependency on a non-existent parameter "foo".

And here is the old one:

You have requested a non-existent parameter "foo".

The new message instantly tells you what you need to look for.

Simpler Doctrine Configuration

Most projects will ever only use one database. But the Doctrine configuration syntax is "optimized" for when you need to be able to manage several database connections. This makes the configuration verbose, non-trivial to understand, and hard to teach:

doctrine:
    dbal:
        connections:
            default:
                dbname:   dbname
                user:     root
                password: ~

As of today, if you only need one database connection, you can use this simpler syntax:

doctrine:
    dbal:
        dbname:   sfweb
        user:     root
        password: ~

Configuring the ORM is also a pain point as every time you add a third-party bundle, you must remember to add it to the Doctrine mapping configuration. If you forget, you will have an error that won't really help you understand what you need to do to fix it.

If you only use one entity manager (which is again the most common use case), you can now just tell Doctrine to automatically load all bundle's mapping configuration:

orm:
    auto_mapping: true

For the record, here is the "old" minimal ORM configuration:

    orm:
        entity_managers:
            default:
                mappings:
                    BlogBundle: ~

The good news is that you can still fallback to the old syntax for the rare occasions where you need more than one database connection or more than one entity manager.

This post is really just a sample of what we are doing on a day to day basis. The good news is that *you** can help us make the framework better. Whenever you hit a wall because an error message is not clear, or because a syntax looks awkward, please tell us about it; write an email to the Symfony developer mailing-list and we will try to work together to make things better and easier. Expect more similar changes in the coming weeks.