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.
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
As well as maybe a counter image for how many times the error has ever occurred to gather aggregate stats for the most error prone parts of the framework.
I realize this is a lot easier to type than it is to make happen, but could prove interesting.
Symfony2 is very flexible and powerful by now. Now it is time to optimise for the common use cases.
Keep up the good work!
Please don't remove any feature just to make it simpler.
Is there any chance the location for Doctrine schema files could be shortened? I made files like this for each entity:
But I'm like, "are you serious? What happened to `config/schema.yml`?"
I like Larry Wall's philosophy about Perl - "make easy things easy and hard things possible".