input and output class refactoring

[dunglas]

Q	A
Bug fix?	no
New feature?	no
BC breaks?	no
Deprecations?	no
Tests pass?	yes
Fixed tickets	#2481
License	MIT
Doc PR	n/a

Alternative to #2481 to get rid of the request attributes and use only the metadata.

TODO:

• Fix tests

[soyuka]

Looks good indeed, it's a bit more work then using the request attributes but it'll be cleaner after! Not sure why I didn't do this from scratch :p.

[ragboyjr]

@dunglas I don't know if this is related to your refactor, but I noticed a few things when testing input classes on 2.4-beta

1. Input classes were request attributes instead of resource/operation attributes (but it looks like this PR addresses that). Having the input class be on the operation makes sense when you want PUT/POST to be different inputs.
2. When using input_class, the input class itself needed to be registered as a resource before it could be used. This kind of makes sense only because of how the internals of API Platform works, but it's not clear from the documentation that this is required, and I'm not sure if that was intended. Because it's a resource, you have to run itemOperations: {}, collectionOperations: {} on all your input classes to remove the inputs.
3. When using messenger with the input classes, you have to specify messenger on the input class definition, and not on the operation metadata. This also makes sense considering how the internals of configuration works, but from a configuration perspective, it feels a bit weird.

Ideally, It'd be great if you could just define the input_class on the operation, API Platform would then default messenger: true since using an input class means you'd need to make a custom data persister or alternatively, use messenger which makes it so much easier to handle and gives you the added benefit that you now have a proper application services for using your app.

App\Entity\Book:
  collectionOperations:
    get: ~
    post:
      # messenger: false (if you want to make a custom data persister)
      input_class: App\DTO\CreateBookRequest

[dunglas]

@ragboyjr thanks for testing!

1. should be fixed now
2. it qualifies at a bug to me
3. it's weird and shouldn't be the case

[ragboyjr]

For 2, and 3, are those things you feel like you want to tackle here, or would you welcome a PR addressing those changes?

[dunglas]

PRs are very welcome!

[bendavies]

missing on-invalid="null"

[norkunas]

Does this supports payload on DELETE request? For example asking user to enter his password before deleting some user related entity.

[soyuka]

it should yes. @GregoireHebert worked on a use case where he uses a PUT and did the removal in a messenger handler :D

[norkunas]

Nice then :)

[Taluu]

oops ?