Non anemic doctrine models are not supported

[Nek-]

I'd like to write my model this way:

class Mail
{
    private $from;
    private $to;
    private $content;
    public function __construct($from, $to, $content)
    {
        $this->from = $from;
        $this->to = $to;
        $this->content = $content;
    }
}

My model looks like this following DDD guidelines.

But with ApiPlatform having this model with a correct (standard) configuration will result in an error of deserialization because fields are not considered as "writable" by the DoctrineOrmPropertyMetadataFactory class. Which is wrong on a Serializer point of view... and even on a Doctrine point of view as this entity is perfectly valid and its fields are also perfectly writable.

To me, this is an issue but @soyuka seems to disagree after a short discussion on slack.

There are many solutions for this problem inside ApiPlatform:

• patch the DoctrineOrmPropertyMetadataFactory 
• patch the SerializerPropertyMetadataFactory (after all if I say they are writable, then they are)
• probably many more as there's also a "configuration" that may set the property writable by default (adding its documentation would be a great help)

There's a last thing about adding a custom PropertyMetadataFactoryInterface (that still needs some documentation) but I don't think it's relevant as to me, ApiPlatform must support this by default (to be compliant with Doctrine and Symfony)

[edit] this has nothing to do with the DoctrineOrmPropertyMetadataFactory.

[dunglas]

For the record, I'm to support this kind of objects. But it will be a tedious work.

[greg0ire]

Another possibility if you're stuck might be to create a DTO to represent the writable fields, then validate it with the Validation component, and if it is valid and only then, attempt to create your entity from that.

[soyuka]

For the record, I'm to support this kind of objects. But it will be a tedious work.

You mean by using the constructor to set the properties?

To me, this is an issue but @soyuka seems to disagree after a short discussion on slack.

Just saying that by default a property in ApiPlatform is considered writable if:

• it has a setter
• or it is publicly available
• or it has an ApiProperty(writable=true) attribute

Your use case is just not supported yet, therefore it's a missing feature (maybe, though can be hotfixed with some metadata manipulation) but not an bug.

[dunglas]

Yes, some improvements have been done in the Symfony serializer to support this use case.

[soyuka]

Yes, some improvements have been done in the Symfony serializer to support this use case.

Though, even with this implemented, these properties will still be considered as readonly if they don't have any setters.

[dunglas]

Until we patch API Platform :)

[DonCallisto]

@greg0ire

Another possibility if you're stuck might be to create a DTO to represent the writable fields, then validate it with the Validation component, and if it is valid and only then, attempt to create your entity from that.

That's what I did (DonCallisto/InterNations@167dd4c#diff-8e21998203ae4e337d28fab5806f49f4R33) but I notice some "issues": first of all, in documentation you'll see a resource that is the DTO whereas the (i.e.:) POST action should refers to real resource.
Second, when I get the response back, I need to implement a listener to change every link that present DTO name into real resource name (DonCallisto/InterNations@167dd4c#diff-8e21998203ae4e337d28fab5806f49f4R43)

If this is the only method here I don't feel that's a good one.
Have you alternative solutions?

If you want to take a look at my solution, here it is https://github.com/DonCallisto/InterNations/tree/api

/cc @dunglas @soyuka

[greg0ire]

I'm not sure we should equate resource and entity, there might be some fields you would not want to publicly expose in there

[DonCallisto]

@greg0ire what do you mean? I use a DTO as a representation of underlying resource. All fields I need to expose would go in the DTO (public), others not.

[greg0ire]

You could see the resource as a representation of the underlying entity is what I'm saying

[teohhanhui]

@greg0ire Hence representations are not resources, and should not be identified as such.