How to Use Data Transformers

How to Use Data Transformers

Data transformers are used to translate the data for a field into a format that can be displayed in a form (and back on submit). They’re already used internally for many field types. For example, the DateType field can be rendered as a yyyy-MM-dd-formatted input text box. Internally, a data transformer converts the starting DateTime value of the field into the yyyy-MM-dd string to render the form, and then back into a DateTime object on submit.

Caution

When a form field has the inherit_data option set to true, data transformers are not applied to that field.

See also

If, instead of transforming the representation of a value, you need to map values to a form field and back, you should use a data mapper. Check out When and How to Use Data Mappers.

Example #1: Transforming Strings Form Data Tags from User Input to an Array

Suppose you have a Task form with a tags text type:

  1. // src/Form/Type/TaskType.php
  2. namespace App\Form\Type;
  4. use App\Entity\Task;
  5. use Symfony\Component\Form\Extension\Core\Type\TextType;
  6. use Symfony\Component\Form\FormBuilderInterface;
  7. use Symfony\Component\OptionsResolver\OptionsResolver;
  9. // ...
  10. class TaskType extends AbstractType
  11. {
  12.     public function buildForm(FormBuilderInterface $builder, array $options): void
  13.     {
  14.         $builder->add('tags', TextType::class);
  15.     }
  17.     public function configureOptions(OptionsResolver $resolver): void
  18.     {
  19.         $resolver->setDefaults([
  20.             'data_class' => Task::class,
  21.         ]);
  22.     }
  24.     // ...
  25. }

Internally the tags are stored as an array, but displayed to the user as a plain comma separated string to make them easier to edit.

This is a perfect time to attach a custom data transformer to the tags field. The easiest way to do this is with the Symfony\Component\Form\CallbackTransformer class:

  1. // src/Form/Type/TaskType.php
  2. namespace App\Form\Type;
  4. use Symfony\Component\Form\CallbackTransformer;
  5. use Symfony\Component\Form\Extension\Core\Type\TextType;
  6. use Symfony\Component\Form\FormBuilderInterface;
  7. // ...
  9. class TaskType extends AbstractType
  10. {
  11.     public function buildForm(FormBuilderInterface $builder, array $options): void
  12.     {
  13.         $builder->add('tags', TextType::class);
  15.         $builder->get('tags')
  16.             ->addModelTransformer(new CallbackTransformer(
  17.                 function ($tagsAsArray) {
  18.                     // transform the array to a string
  19.                     return implode(', ', $tagsAsArray);
  20.                 },
  21.                 function ($tagsAsString) {
  22.                     // transform the string back to an array
  23.                     return explode(', ', $tagsAsString);
  24.                 }
  25.             ))
  26.         ;
  27.     }
  29.     // ...
  30. }

The CallbackTransformer takes two callback functions as arguments. The first transforms the original value into a format that’ll be used to render the field. The second does the reverse: it transforms the submitted value back into the format you’ll use in your code.

Tip

The addModelTransformer() method accepts any object that implements Symfony\Component\Form\DataTransformerInterface - so you can create your own classes, instead of putting all the logic in the form (see the next section).

You can also add the transformer, right when adding the field by changing the format slightly:

  1. use Symfony\Component\Form\Extension\Core\Type\TextType;
  3. $builder->add(
  4.     $builder
  5.         ->create('tags', TextType::class)
  6.         ->addModelTransformer(...)
  7. );

Example #2: Transforming an Issue Number into an Issue Entity

Say you have a many-to-one relation from the Task entity to an Issue entity (i.e. each Task has an optional foreign key to its related Issue). Adding a list box with all possible issues could eventually get really long and take a long time to load. Instead, you decide you want to add a text box, where the user can enter the issue number.

Start by setting up the text field like normal:

  1. // src/Form/Type/TaskType.php
  2. namespace App\Form\Type;
  4. use App\Entity\Task;
  5. use Symfony\Component\Form\Extension\Core\Type\TextareaType;
  6. use Symfony\Component\Form\Extension\Core\Type\TextType;
  8. // ...
  9. class TaskType extends AbstractType
  10. {
  11.     public function buildForm(FormBuilderInterface $builder, array $options): void
  12.     {
  13.         $builder
  14.             ->add('description', TextareaType::class)
  15.             ->add('issue', TextType::class)
  16.         ;
  17.     }
  19.     public function configureOptions(OptionsResolver $resolver): void
  20.     {
  21.         $resolver->setDefaults([
  22.             'data_class' => Task::class,
  23.         ]);
  24.     }
  26.     // ...
  27. }

Good start! But if you stopped here and submitted the form, the Task’s issue property would be a string (e.g. “55”). How can you transform this into an Issue entity on submit?

Creating the Transformer

You could use the CallbackTransformer like earlier. But since this is a bit more complex, creating a new transformer class will keep the TaskType form class simpler.

Create an IssueToNumberTransformer class: it will be responsible for converting to and from the issue number and the Issue object:

  1. // src/Form/DataTransformer/IssueToNumberTransformer.php
  2. namespace App\Form\DataTransformer;
  4. use App\Entity\Issue;
  5. use Doctrine\ORM\EntityManagerInterface;
  6. use Symfony\Component\Form\DataTransformerInterface;
  7. use Symfony\Component\Form\Exception\TransformationFailedException;
  9. class IssueToNumberTransformer implements DataTransformerInterface
  10. {
  11.     private $entityManager;
  13.     public function __construct(EntityManagerInterface $entityManager)
  14.     {
  15.         $this->entityManager = $entityManager;
  16.     }
  18.     /**
  19.      * Transforms an object (issue) to a string (number).
  20.      *
  21.      * @param  Issue|null $issue
  22.      */
  23.     public function transform($issue): string
  24.     {
  25.         if (null === $issue) {
  26.             return '';
  27.         }
  29.         return $issue->getId();
  30.     }
  32.     /**
  33.      * Transforms a string (number) to an object (issue).
  34.      *
  35.      * @param  string $issueNumber
  36.      * @throws TransformationFailedException if object (issue) is not found.
  37.      */
  38.     public function reverseTransform($issueNumber): ?Issue
  39.     {
  40.         // no issue number? It's optional, so that's ok
  41.         if (!$issueNumber) {
  42.             return null;
  43.         }
  45.         $issue = $this->entityManager
  46.             ->getRepository(Issue::class)
  47.             // query for the issue with this id
  48.             ->find($issueNumber)
  49.         ;
  51.         if (null === $issue) {
  52.             // causes a validation error
  53.             // this message is not shown to the user
  54.             // see the invalid_message option
  55.             throw new TransformationFailedException(sprintf(
  56.                 'An issue with number "%s" does not exist!',
  57.                 $issueNumber
  58.             ));
  59.         }
  61.         return $issue;
  62.     }
  63. }

Like the first example, the transformer has two directions. The transform() method is responsible for converting the data used in your code to a format that can be rendered in your form (e.g. an Issue object to its id, a string). The reverseTransform() method does the reverse: it converts the submitted value back into the format you want (e.g. convert the id back to the Issue object).

To cause a validation error, throw a Symfony\Component\Form\Exception\TransformationFailedException. But the message you pass to this exception won’t be shown to the user. You’ll set that message with the invalid_message option (see below).

Note

When null is passed to the transform() method, your transformer should return an equivalent value of the type it is transforming to (e.g. an empty string, 0 for integers or 0.0 for floats).

Using the Transformer

Next, you need to use the IssueToNumberTransformer object inside of TaskType and add it to the issue field. No problem! Add a __construct() method and type-hint the new class:

  1. // src/Form/Type/TaskType.php
  2. namespace App\Form\Type;
  4. use App\Form\DataTransformer\IssueToNumberTransformer;
  5. use Symfony\Component\Form\Extension\Core\Type\TextareaType;
  6. use Symfony\Component\Form\Extension\Core\Type\TextType;
  8. // ...
  9. class TaskType extends AbstractType
  10. {
  11.     private $transformer;
  13.     public function __construct(IssueToNumberTransformer $transformer)
  14.     {
  15.         $this->transformer = $transformer;
  16.     }
  18.     public function buildForm(FormBuilderInterface $builder, array $options): void
  19.     {
  20.         $builder
  21.             ->add('description', TextareaType::class)
  22.             ->add('issue', TextType::class, [
  23.                 // validation message if the data transformer fails
  24.                 'invalid_message' => 'That is not a valid issue number',
  25.             ]);
  27.         // ...
  29.         $builder->get('issue')
  30.             ->addModelTransformer($this->transformer);
  31.     }
  33.     // ...
  34. }

Whenever the transformer throws an exception, the invalid_message is shown to the user. Instead of showing the same message every time, you can set the end-user error message in the data transformer using the setInvalidMessage() method. It also allows you to include user values:

  1. // src/Form/DataTransformer/IssueToNumberTransformer.php
  2. namespace App\Form\DataTransformer;
  4. use Symfony\Component\Form\DataTransformerInterface;
  5. use Symfony\Component\Form\Exception\TransformationFailedException;
  7. class IssueToNumberTransformer implements DataTransformerInterface
  8. {
  9.     // ...
  11.     public function reverseTransform($issueNumber): ?Issue
  12.     {
  13.         // ...
  15.         if (null === $issue) {
  16.             $privateErrorMessage = sprintf('An issue with number "%s" does not exist!', $issueNumber);
  17.             $publicErrorMessage = 'The given "{{ value }}" value is not a valid issue number.';
  19.             $failure = new TransformationFailedException($privateErrorMessage);
  20.             $failure->setInvalidMessage($publicErrorMessage, [
  21.                 '{{ value }}' => $issueNumber,
  22.             ]);
  24.             throw $failure;
  25.         }
  27.         return $issue;
  28.     }
  29. }

New in version 4.3: The setInvalidMessage() method was introduced in Symfony 4.3.

That’s it! If you’re using the default services.yaml configuration, Symfony will automatically know to pass your TaskType an instance of the IssueToNumberTransformer thanks to autowire and autoconfigure. Otherwise, register the form class as a service and tag it with the form.type tag.

Now, you can use your TaskType:

  1. // e.g. somewhere in a controller
  2. $form = $this->createForm(TaskType::class, $task);
  4. // ...

Cool, you’re done! Your user will be able to enter an issue number into the text field, which will be transformed back into an Issue object. This means that, after a successful submission, the Form component will pass a real Issue object to Task::setIssue() instead of the issue number.

If the issue isn’t found, a form error will be created for that field and its error message can be controlled with the invalid_message field option.

Caution

Be careful when adding your transformers. For example, the following is wrong, as the transformer would be applied to the entire form, instead of just this field:

  1. // THIS IS WRONG - TRANSFORMER WILL BE APPLIED TO THE ENTIRE FORM
  2. // see above example for correct code
  3. $builder->add('issue', TextType::class)
  4.     ->addModelTransformer($transformer);

Creating a Reusable issue_selector Field

In the above example, you applied the transformer to a normal text field. But if you do this transformation a lot, it might be better to create a custom field type. that does this automatically.

First, create the custom field type class:

  1. // src/Form/IssueSelectorType.php
  2. namespace App\Form;
  4. use App\Form\DataTransformer\IssueToNumberTransformer;
  5. use Symfony\Component\Form\AbstractType;
  6. use Symfony\Component\Form\Extension\Core\Type\TextType;
  7. use Symfony\Component\Form\FormBuilderInterface;
  8. use Symfony\Component\OptionsResolver\OptionsResolver;
  10. class IssueSelectorType extends AbstractType
  11. {
  12.     private $transformer;
  14.     public function __construct(IssueToNumberTransformer $transformer)
  15.     {
  16.         $this->transformer = $transformer;
  17.     }
  19.     public function buildForm(FormBuilderInterface $builder, array $options): void
  20.     {
  21.         $builder->addModelTransformer($this->transformer);
  22.     }
  24.     public function configureOptions(OptionsResolver $resolver): void
  25.     {
  26.         $resolver->setDefaults([
  27.             'invalid_message' => 'The selected issue does not exist',
  28.         ]);
  29.     }
  31.     public function getParent(): string
  32.     {
  33.         return TextType::class;
  34.     }
  35. }

Great! This will act and render like a text field (getParent()), but will automatically have the data transformer and a nice default value for the invalid_message option.

As long as you’re using autowire and autoconfigure, you can start using the form immediately:

  1. // src/Form/Type/TaskType.php
  2. namespace App\Form\Type;
  4. use App\Form\DataTransformer\IssueToNumberTransformer;
  5. use Symfony\Component\Form\Extension\Core\Type\TextareaType;
  6. // ...
  8. class TaskType extends AbstractType
  9. {
  10.     public function buildForm(FormBuilderInterface $builder, array $options): void
  11.     {
  12.         $builder
  13.             ->add('description', TextareaType::class)
  14.             ->add('issue', IssueSelectorType::class)
  15.         ;
  16.     }
  18.     // ...
  19. }

Tip

If you’re not using autowire and autoconfigure, see How to Create a Custom Form Field Type for how to configure your new IssueSelectorType.

About Model and View Transformers

In the above example, the transformer was used as a “model” transformer. In fact, there are two different types of transformers and three different types of underlying data.

../_images/data-transformer-types.png

In any form, the three different types of data are:

  1. Model data - This is the data in the format used in your application (e.g. an Issue object). If you call Form::getData() or Form::setData(), you’re dealing with the “model” data.
  2. Norm Data - This is a normalized version of your data and is commonly the same as your “model” data (though not in our example). It’s not commonly used directly.
  3. View Data - This is the format that’s used to fill in the form fields themselves. It’s also the format in which the user will submit the data. When you call Form::submit($data), the $data is in the “view” data format.

The two different types of transformers help convert to and from each of these types of data:

Model transformers:

  • transform(): “model data” => “norm data”
  • reverseTransform(): “norm data” => “model data”

View transformers:

  • transform(): “norm data” => “view data”
  • reverseTransform(): “view data” => “norm data”

Which transformer you need depends on your situation.

To use the view transformer, call addViewTransformer().

So why Use the Model Transformer?

In this example, the field is a text field, and a text field is always expected to be a simple, scalar format in the “norm” and “view” formats. For this reason, the most appropriate transformer was the “model” transformer (which converts to/from the norm format - string issue number - to the model format - Issue object).

The difference between the transformers is subtle and you should always think about what the “norm” data for a field should really be. For example, the “norm” data for a text field is a string, but is a DateTime object for a date field.

Tip

As a general rule, the normalized data should contain as much information as possible.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.