Consider the following scenario
We have a simple database that involves two entities: user and category.
For our hypothesis let’s say that a user can have only a type of category and a category can be associated with n users.
Now, consider a web page where a user – say ROLE_ADMINISTRATOR – could edit user table and associate them to a different one category.
As far I know (and I’m still new to symfony in general) if I use Doctrine and symfony2 in tandem, with – let’s say – annotation method, i’ll have two entity (php classes).
Embedded form
I will create a form that will show the user and, for show – and persist, of course! – also his category I “choose” to follow the “embedded form” strategy.
Having said that the entity has been created, i’ll have to create a form for category (suppose that into formBuilder I’ll add only id attribute of the category).
After that I have to add to formBuilder of UserType class the previous form and, with “some kind of magic” the form will render (after the appropriate operations) as magic and just as magically, when i’ll post it (and bind, and so on) back all the informations will be persists onto database
Data Transformers
A.K.A. trasnform an input of a form into an object and vice versa.
In that way I’ll have to define a – let’s say – CategorySelectorType that into his builder, will add a Class (service ?) that will do those transformations.
Now we define the data transformer itself that will implement the DataTransofmerInterface (with his method and so on…)
The next step will be register that entity into services and add into UserType the form that will use this service.
So I don’t understand any “strong” difference between those two metodology but “reusability” of the service. Somebody can offer me a different point of view and explain me the differences, if any?
A data transformer does not replace a embedded form, it rather enhances forms and wraps data transformation nicely.
The first sentence on the cookbook page about Data Transformers sums it up nicely:
In your example above, you could add a drop-down list of categories so the admin can select one for the given user. This would be done using a embedded form. As the category field is the id of an existing category, there is no need to transform the data.
For some reason you now want the admin to be able to enter a free text of the category. Now you need to do some tranformation of the text into the object in question. Maybe you want him to be able to either add a new or select a current category with this text field. Both is possible by using a data transformer which takes the text and searches for the category. Depending on your needs, not existing categories can be created and returned.
Another use case is when a user enters data which needs to be modified in some way before storing them. Let’s say the user enters a street, house number and city but you want to store the coordinates instead.
In both cases it doesn’t matter if you embed the form into another!
Could you do that in your controller? Of course. Is it a good idea to do such things in the controller? Probably not, as you have a hard time testing (while doing it in the transformer let you unit test the transformation nicely) or reusing it.
UPDATE
Of course it is possible to place the transformation code someplace else. The user object itself is not a good place, as the model should not know about the entity manager, which is needed to do the transformation.
The user type would be possible, but this means that it gets tied to the entity manager.
It all adds up to the very powerfull concept of Separation of concerns, which states that one class should only do one thing to make it maintainable, resuable, testable and so on. If you follow this concept, than it should be clear that data transformation is a thing on its own and should be threated as such. If you don’t care, you may not need the transformation functionality.