While creating a system at Infinite*, I came across the requirement that we have a form collection that could cope with single table inheritance used by Doctrine2. We have Invoices with many different kinds of lines that would reference back to whatever object they were about, but all contained common basic parameters common to all invoice lines.
Enter the Polycollection.
Since version 2.2.0, Doctrine ships with a really handy listener, ResolveTargetEntityListener that lets you keep your bundles separated, while still letting you define loose relationships between different entities.
What this listener allows you to do is define a relationship target in your entities that will be replaced at runtime. This becomes very useful when you’ve got different bundles doing different things, and want to have relationships between them, but not defining dependencies between those bundles.
In almost every situation, developers will always prefer to create a brand new application rather than migrate a legacy application. When you migrate an application, there is a large amount of baggage that needs to be accounted for which means that you may end up spending a large amount of time dealing with the legacy baggage.
On top of this, sometimes applications can be so large that it can be almost impossible to rewrite the entire application in one go. Another option is to slowly migrate features only a few at a time while introducing tests to make sure that you’re not breaking any front-end functionality.
Something that comes up every so often is how to convert the name of a property into a getter or setter, and generally the solution proposed is something like the following.
1 2 3 4 | |
While this might be an acceptable method, there are more elegant solutions, one of which is using the PropertyPath utility provided by the Symfony2 Form component.
The PropertyPath utility provides more advanced functionality, which will search for a getter, isser or hasser method, then fall back to trying to access the property itself.
FOSCommentBundle recently added functionality that allows you to use some kind of markup parser to let your users post more than just plain text comments. The way it is implemented allows the developer to choose which parser for whatever language they desire.
In this article, we assume you are using Symfony2.0 with the deps file and bin/vendor management. For Symfony2.1 users, you are able to replace the parts of the instructions with composer, which is beyond the scope of this article.