Recetly, I needed to implement a quite simple serializer that would be used to prepare the entities from the database for indexing in ElasticSearch. I didn’t really need to get JSON or XML out of it, I only needed to transform my objects into arrays.
Instead of hacking around Symfony’s built-in Serializer or JMSSerializer (I’m not sure whether it’s simple to get just the data array out of those), I’ve decided I can do it in a lot more simple way just with PropertyAccess.

PropertyAccess is a base Symfony component, commonly used in forms, but there’s nothing limiting its usage in different contexts. The whole aim of the component is to allow an easy way to read and write from and to objects and arrays. Its API is quite simple and straightforward:

use Symfony\Component\PropertyAccess\PropertyAccess;

$accessor = PropertyAccess::createPropertyAccessor();
$hello = array(
    'greeted' =>

Despite the fact that ORMs are quite evil, often we cannot escape this burden because the decision about using or not using an ORM was taken by someone else on the team, maybe way before we could affect this decision somehow. Well, ORMs are, of course, not always a good thing to have, but misusing them is even worse.

I’m using Symfony, but other advanced ORMs such as Hibernate in Java or Entity framework in C support ORM events as well, so the ideas I’m sharing here should be generally applicable to these platforms as well.

After some digging on StackOverflow, I’ve noticed a common pattern with ORMs and persistence events these ORMs provide: people tend to attach their listeners to entity lifecycle events and implement business rules there. Here’s an example from Symfony’s DoctrineBundle documentation:

namespace AppBundle\EventListener;

use Doctrine\ORM\Event\LifecycleEventArgs;
use

Lately, I took some time looking through [PageKit CMS](github.com/pagekit/pagekit). It’s a nice project, based on Symfony components and Pimple DI container. Current version is 1.0, so the API is pretty stable and people can start developing extensions and themes.

However, I’ve found some problems here and there, and would like to talk about them, hoping that some of my suggestions might find their way into implementation.

Forms

First, Pagekit guys aren’t using Symfony’s Form component (which is a bit complicated, but nevertheless, awesome). Entity editors are implemented as plain HTML forms with a parameter array.

We need events!

When an edit form is being rendered, no events are dispatched, and there is no way for my extension to detect that the blog post editor is going to render a textarea for the post content.

So, if I decided to implement a plugin for CKEditor, or Redactor...

There’s always the need to abstract out our data persistence mechanisms so that we don’t have to mess with mapping user data to tables by hand and handling the relations between user data entities.

I’ve been always using Doctrine ORM in my Symfony 2 projects. But at some moment I’ve been forced into using Propel 1.7, as it’s a corporate standard.

And oh my god, it’s just a load of crap. See for yourself:

• The model code is automatically generated from a schema, which means that you cannot ever be sure that your schema changes won’t break the model interface.
• The schema.xml format is counterintuitive, you have to dig through the docs most of the times you want to change something there.
• You cannot import different schemas during DI container compilation. This means that a schema cannot be modified depending on your bundle’s configuration.

What’s the worst of it all is that Propel is...