feat(symfony): object mapper with state options

[soyuka]

Q	A
Branch?	main
License	MIT

Still a few things left to be done but this is a first approach. This makes API Platform compatible with the Object Mapper component: symfony/symfony#51741

Demo:

composer create-project symfony/skeleton test-objectmapper2
cd test-objectmapper2
composer req debug api-platform/symfony api-platform/doctrine-orm make orm symfony/asset 
nvim .env # uncomment sqlite
nvim composer.json # change extra.symfony to 7.3.*
composer config minimum-stability RC
composer req symfony/object-mapper:^7.3.0-RC1 symfony/type-info:v7.3.0-RC1 symfony/framework-bundle:v7.3.0-RC1 -W 
# clone my pr https://github.com/api-platform/core/pull/6801 to a parent directory:
# example with gh in a api-platform/core clone: `gh pr checkout 6801`
composer link ../core-6801 # if link is not available `composer global require soyuka/pmu`
bin/console make:entity # create an entity Book with id/title
bin/console d:s:u --force 
frankenphp php-server --listen :8080 -r public

Example:

<?php

namespace App\Entity;

use App\ApiResource\Book as AppBook;
use App\Repository\BookRepository;
use Doctrine\ORM\Mapping as ORM;
use Symfony\Component\ObjectMapper\Attribute\Map;

#[ORM\Entity(repositoryClass: BookRepository::class)]
#[Map(target: AppBook::class)]
class Book
{
    #[ORM\Id]
    #[ORM\GeneratedValue]
    #[ORM\Column]
    private ?int $id = null;

    #[ORM\Column(length: 255)]
    #[Map(transform: 'ucfirst')] // example of transformation to the dto
    private ?string $title = null;

    public function getId(): ?int
    {
        return $this->id;
    }

    public function getTitle(): ?string
    {
        return $this->title;
    }

    public function setTitle(string $title): static
    {
        $this->title = $title;

        return $this;
    }
}

<?php

namespace App\ApiResource;

use ApiPlatform\Doctrine\Orm\State\Options;
use ApiPlatform\Metadata\ApiResource;
use App\Entity\Book as BookEntity;
use Symfony\Component\ObjectMapper\Attribute\Map;

#[ApiResource(stateOptions: new Options(entityClass: BookEntity::class))]
#[Map(target: BookEntity::class)]
class Book
{
    #[Map(if: false)] // do not map the id from the dto to the entity
    public string $id;
    #[Map(transform: 'strtolower')] // example of transformation
    public string $title;
}

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[GromNaN]

I think these provider and processor are Doctrine-specific. They should be moved to the Doctrine namespace and we can consider injecting the ObjectManager of ORM or ODM to retrieve the attached object.

Unless the new symfony/mapper component is able to use a factory to create the Entity class from the DTO. It would use the Id field of the DTO to retreive the attached entity from the entity manager.

[GromNaN]

If that can help, I use this script to link external directories in my project vendors: https://gist.github.com/GromNaN/020dd50fc3ed71d31ebc548bb75845e7

[soyuka]

I built https://github.com/soyuka/pmu for that now :p

[GromNaN]

In PATCH and DELETE operations, you must map into the entity attached to the EntityManager when retrieved in the provider.

Otherwise the decorated doctrine processor will try to persist a new object (and maybe fail on duplicate primary key), or skip removing the non-persisted entity.

[SebLevDev]

Isn't it necessary to include the entity in the context for PUT operations?
Here’s an example of what I had done for a DtoToEntityProcessor:

$this->validator->validate($data);
$entity = $this->mapDtoToEntity($data, $entityClass, $context);

$context['previous_data'] = $entity;
$entity = $this->persistProcessor->process($entity, $operation, $uriVariables, $context);
$data->id = $entity->getId();

[GromNaN]

The DenormalizeProvider already create an instance of the operation class. Mapping into the same target class as the source class doesn't seem a valid use case to me. Making this provider useful only with Doctrine.

[soyuka]

The denormalizer provider is only called on write operations. but indeed they should be doctrine-oriented it would make more sense

[soyuka]

@GromNaN this is probably fixing the issue you commented about the denormalizer.

Could you review again?

[soyuka]

I'll fix the tests once the component is released