Symfony

In my previous post, I tried to answer the following question: how do you keep your Doctrine repositories from growing exponentially? Long story short, I came up with a generic solution based on the Specification pattern that essentially abstracts and simplifies the way we write and compose queries. And the best part is that it works with Doctrine but also with any other data-source. RulerZ was born. Of course, there was a real need behind my previous question. For one of my current projects, I wanted to be able to switch from one data-source to another. My application would use Doctrine in development and production environment but for tests I wanted my data to live in memory. ...

Here is a digest of the best practices that are commonly followed for Symfony2 projects. They are given as is, in no particular order and are far from being exhaustive. Naming things find a common naming scheme for your team and stick to it be explicit be consistent same for routes and services naming use service alias: mailer is better than swiftmailer.mailer.default prefer Vendor/Bundle/CoolBundle over Vendor/CoolBundle for bundles namespace for an application, you can even skip the vendor part Config Which configuration format should you use? ...

Important : as j0k pointed out in the comments, Symfony 2.5 changed the way validation files are loaded. Refer to this StackOverflow answer if you are using Symfony >= 2.5. Defining validation rules for several entities in the same file can really be a pain. Unfortunately, Symfony2 only looks in the validation.yml file by default. Let’s see how we can split the following file: The solution lies in the AcmeBlogExtension class, and more specifically in the validator.mapping.loader.yaml_files_loader.mapping_files parameter. As this parameter defines the list of files used to map configuration rules to their entities, we just have to add our owns to the list. ...