Constructor relations writtable

[komik966]

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	#2169
License	MIT
Doc PR	todo

Connected with: #1749, symfony/symfony#28263

TODO:

• make documentation normalizers (+ GraphQL?) aware of VOs
• add unit tests

[komik966]

For now I've made Swagger\DocumentationNormalizer to not add readOnly label when property is initializable.

But I think that it can be more guessable, consider example:
Users can change theirs password but not email:

class User
{
    private $email;
    private $password;

    public function __construct(string $email) { $this->email = $email; }

    public function getEmail(): string { return $this->email; }

    public function getPassword(): string { return $this->password; }

    public function setPassword(string $password): void { $this->password = $password; }
}

Then documentation should looks like this:

POST - input / output
{
  "email": "string",
  "password": "string"
}

PUT - input
{
  "password": "string"
}

PUT - output
{
  "email": "string",
  "password": "string"
}

Such documentation behavior will allow us generating CRUD clients with distinction between what should appear in create form and what in update form, without the need to define serialization groups.

If we're ok with this, I prefer to create it in different PR. For now non writable properties are included in documentation for PUT methods, but are ignored during request - check it:

core/features/serializer/vo_relations.feature

Line 83 in 4309ffe

Scenario: Update Value object with writable and non writable property

[dunglas]

Only a minor change, then 👍 on my side

[dunglas]

Please mark it as @internal because we'll remove it at some point.

[komik966]

Done

[teohhanhui]

a -> an

[komik966]

👍 Fixed

[maks-rafalko]

please, don't forget to update documentation.

It's so painful when documentation is updated post-factum by someone who spends hours debugging, not in advance.

thanks for this feature btw!

[bendavies]

can this error be more consumer friendly on serialization? it's exposing implementation detail to the consumer which they don't care about: the class name, overly verbose message etc... all the consumer needs to know is that they didn't provide the some parameter.

[komik966]

This code comes from symfony/serializer (see method comment). So I'm not sure if we should change it. But I've similar opinion. Ideally would be to show such errors the same way as validation errors (as map: property => error message). I think that non nullable and without default value constructor parameters are equivalent to class attributes with NotBlank constraint (with some exceptions) and errors should be presented the same way.