Repository navigation
Allow to autoconfigure validation groups generators - #3346
Conversation
5ec89da to
a067974
Compare
soyuka
left a comment
There was a problem hiding this comment.
nice job, we should add a unit test implementing a validationgroupsgenerator
a067974 to
573bb2e
Compare
|
Also updated return typehint from generator interface not to be strict and allow return GroupSequence for consistency. |
573bb2e to
f56d598
Compare
f56d598 to
9d7b535
Compare
|
ping :) |
b7450e4 to
0a6a90f
Compare
|
Updated, but I don't understand what's wrong with the tests. How a single definition can affect another definitions 🤔 |
Looks like there's a missing mock? |
Which mock? |
The My suggestion is to add: $this->childDefinitionProphecy->addTag(Argument::type('string'))->willReturn($this->childDefinitionProphecy);in |
0a6a90f to
d6ac314
Compare
d6ac314 to
f4d76e5
Compare
Didn't help 🤦♂️ 😁 |
|
Let me fix this... |
62a5f85 to
5a4484c
Compare
5a4484c to
08a10f5
Compare
Co-authored-by: Teoh Han Hui <teohhanhui@gmail.com>
08a10f5 to
39fc0a4
Compare
|
Thanks @norkunas! 🎉 🚀 |
When having many validation groups generators for resources, you need to make every generator as a public service, and this doesn't work with
_instanceofconfiguration where you could add a custom marker and make those services public, because symfony doesn't detect that those services are used and removes from container.This adds
ApiPlatform\Core\Validator\ValidationGroupsGeneratorInterfaceso apps can leverage the autoconfiguration + autowiring of those generators. Generators are collected and registered in a custom service locator, but consumers won't need anymore any configuration for them if will implement the interface. For not breaking backwards compatibility left the full service container as a fallback.TODO: