You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR was squashed before being merged into the 6.4 branch.
Discussion
----------
[FrameworkBundle][Validator] Allow implementing validation groups provider outside DTOs
| Q | A
| ------------- | ---
| Branch? | 6.4
| Bug fix? | no
| New feature? | yes
| Deprecations? | no
| Tickets | -
| License | MIT
| Doc PR | symfony/symfony-docs#18744
Alternative to symfony/symfony#51233
Inspiration: symfony/symfony#51012
Currently, you can determine the sequence of groups to apply dynamically based on the state of your DTO by implementing the `GroupSequenceProviderInterface` in your DTO class. https://symfony.com/doc/current/validation/sequence_provider.html#group-sequence-providers
```php
use Symfony\Component\Validator\GroupSequenceProviderInterface;
#[Assert\GroupSequenceProvider]
class UserDto implements GroupSequenceProviderInterface
{
// ...
public function getGroupSequence(): array|GroupSequence
{
if ($this->isCompanyType()) {
return ['User', 'Company'];
}
return ['User'];
}
}
```
It covers most of the common scenarios, but for more advanced ones, it may not be sufficient. Suppose now you need to provide the sequence of groups from an external configuration (or service) which can change its value dynamically:
```php
#[Assert\GroupSequenceProvider]
class UserDto implements GroupSequenceProviderInterface
{
// ...
public __constructor(private readonly ConfigService $config)
{
}
public function getGroupSequence(): array|GroupSequence
{
if ($this->config->isEnabled()) {
return ['User', $this->config->getGroup()];
}
return ['User'];
}
}
```
This issue cannot be resolved at present without managing the DTO initialization and manually setting its dependencies. On the other hand, since the state of the DTO is not used at all, the implementation of the `GroupSequenceProviderInterface` becomes less fitting to the DTO responsibility. Further, stricter programming may raise a complaint about a violation of SOLID principles here.
So, the proposal of this PR is to allow configuring the validation groups provider outside of the DTO, while simultaneously enabling the registration of this provider as a service if necessary.
To achieve this, you'll need to implement a new `GroupProviderInterface` in a separate class, and configure it using the new `provider` option within the `GroupSequenceProvider` attribute:
```php
#[Assert\GroupSequenceProvider(provider: UserGroupProvider::class)]
class UserDto
{
// ...
}
class UserGroupProvider implements GroupProviderInterface
{
public __constructor(private readonly ConfigService $config)
{
}
public function getGroups(object $object): array|GroupSequence
{
if ($this->config->isEnabled()) {
return ['User', $this->config->getGroup()];
}
return ['User'];
}
}
```
That's all you'll need to do if autowiring is enabled under your custom provider. Otherwise, you can manually tag your service with `validator.group_provider` to collect it and utilize it as a provider service during the validation process.
In conclusion, no more messing with the DTO structure, just use the new `class` option for more advanced use cases.
---
TODO:
- [x] Add tests
- [x] Create doc PR
Commits
-------
a3a089a15b8 [FrameworkBundle][Validator] Allow implementing validation groups provider outside DTOs
0 commit comments