[make:validator] Add --target option that allows restricting automatically where the constraint class can be used

[nxtpge]

Q	A
Branch?	1.x
Bug fix?	no
New feature?	yes
Deprecations?	no
Issues
License	MIT

This pull request adds the --target option to the make:validator command to speed up the creation and the use of a custom validation constraint.

Usage

php bin/console make:validator FooValidator --target=class
php bin/console make:validator FooValidator --target=method
php bin/console make:validator FooValidator --target=property

Result

Target	Constraint class changes
class	- Add the #[\Attribute(\Attribute::IS_REPEATABLE)] declaration, - Add the Constraint::getTargets required method.
method	- Add the #[\Attribute(\Attribute::TARGET_METHOD | \Attribute::IS_REPEATABLE)] declaration.
property	- Add the #[\Attribute(\Attribute::TARGET_PROPERTY | \Attribute::IS_REPEATABLE)] declaration.

[javiereguiluz]

Just asking: should we also support multiple targets? Is it a common enough need?

If yes, should we support multiple values in the option: --target=class,method or go with the classic Symfony array option: --target=class --target=method?

Also, ideally the Maker bundle should ask some questions when creating classes like these so you can choose the target, etc. In the past I thought that Maker souldn't bother users too much with questions ... but lately I think it'd be better to ask some questions as long as are for common needs and questions are fully understandable even if you are a newcomer.

[nxtpge]

Hello @javiereguiluz and thank you for reaching out about this feature.

Just asking: should we also support multiple targets? Is it a common enough need?

From my point of view, multiple targets may happen in one case: a validation constraint on both a method and a property.

On one hand, I agree with you about allowing a developer to be free to choose any case that might suit his needs.

On the other hand, I think we should not encourage such behavior as having both class and method|property targets at the same time seems to be a bad practice, at least for me.

Indeed, it would require the custom ConstraintValidator to handle both cases and be more complex than necessary in the developer's codebase.

I let you decide with the Core team members if we should be opinionated or not in this situation.

An "all-in-one" solution would be to allow multiple targets and providing some guidance (notice or warning) in the documentation.

Also, ideally the Maker bundle should ask some questions when creating classes like these so you can choose the target, etc.

As you said, for a newcomer it will be understandable which is good.

For an "experienced" developer, since the command is already used, I think adding questions will negatively impact his experience (from a quick process to a slowed down one).

I am open to your insights.