A place to experiment

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.

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.

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.