4 Matching Annotations
  1. Last 7 days
    1. pecial action-based dependency injection

      DO NOT USE IT. Can tie your own hands. Rely on normal DI.

  2. Nov 2019
    1. Instead of using the empty_data option – which is only called if we create an object, but not if we update it – we will implement a custom data mapper. Symfony's data mappers are responsible for mapping the data of a form to its fields and back. For our MoneyType, Symfony's default data mapper will call the following methods when we display a form with an existing Money instance: $form->get('amount')->setData($money->getAmount()); $form->get('currency')->setData($money->getCurrency()); The properties of the Money are copied to the form simply by calling the appropriate getters. When we submit the form, the data mapper inverts that behavior: $money->setAmount($form->get('amount')->getData()); $money->setCurrency($form->get('currency')->getData()); That's where the data mapper fails. The setters setAmount() and setCurrency() don't exist. To create a custom data mapper we need to implement DataMapperInterface. Let's look at this interface: namespace Symfony\Component\Form; interface DataMapperInterface { /** * Maps properties of some data to a list of forms. * * @param mixed $data Structured data. * @param FormInterface[] $forms A list of {@link FormInterface} instances. */ public function mapDataToForms($data, $forms); /** * Maps the data of a list of forms into the properties of some data. * * @param FormInterface[] $forms A list of {@link FormInterface} instances. * @param mixed $data Structured data. */ public function mapFormsToData($forms, &$data); } These methods correspond to the two previous code blocks. The method mapDataToForms() calls setData() on all passed forms by reading the passed $data. Conversely, mapFormsToData() updates $data by reading the data of the passed forms.

      This is so important & useful, when working in DDD & immutability, where setters are avoided.

  3. Oct 2019
    1. This can become messy when you have a lot of configurations in your Entity. Another issue is that your annotations are coupled to your source code. Your database implementations details, or any other configurations are coupled to your domain object. This goes against the guidelines of clean code. Your domain object (Entity) should only have one reason to change.

      Thank you for saying that loud.