[Validator] Standardize constraint validators #28645

ro0NL · 2018-09-30T09:10:06Z

Q	A
Branch?	master
Bug fix?	no
New feature?	yes
BC breaks?	no-ish
Deprecations?	no
Tests pass?	yes
Fixed tickets	#...
License	MIT
Doc PR	symfony/symfony-docs#...

there are subtle inconsistencies between constraint validators, esp. related to string values. I think we should tackle it, by taking away the boring stuff.

constraint type isnt always checked
casting objects to string doesnt always happen
checking empty string after casting doesnt always happen
the order of checks isnt always the same

This would help custom constraints, as well as core to e.g. deprecate empty string handling in a unified way (#28611).

ostrolucky · 2018-09-30T18:43:08Z

Regarding changing how exceptions are being thrown, tread lightly. Current design how invalid types are handled is faulty because it causes 500s even when there is @Type constraint, so spreading this design to all constraints does not make sense.

See
#12312
#26463

ro0NL · 2018-09-30T18:47:07Z

that should be solved by #27917 right, here we just move code around.

ostrolucky · 2018-09-30T19:01:39Z

If it gets merged, yeah

gmponos · 2018-10-01T08:19:13Z

Don't get me wrong, but I believe that the method names that you have are not descriptive on what the methods are actually doing.

testConstraint gives me the feeling that the constraint will be executed and tested. Personally I would prefer something like assertConstraintClass
toString gives the feeling that the Constraint class it's self will be converted to string. Something like convertValueToString would be better for me.

OskarStark · 2018-10-01T21:30:27Z

src/Symfony/Component/Validator/Constraints/BicValidator.php

@@ -9,12 +9,13 @@
 * file that was distributed with this source code.
 */

+use Symfony\Component\Validator\Constraints\Bic;


The use statement should be below the namespace

ro0NL · 2018-10-02T04:58:30Z

@gmponos thanks :) i did it a bit quick to propose the idea... we can talk about naming any time, but i think your suggestion is better yes.

i like assertConstraint() + getStringValue() too :) i havent looked into all constraint yes, but we might add getNumberValue() as well (what's needed i'd say).

nicolas-grekas · 2018-10-03T06:16:11Z

src/Symfony/Component/Validator/ConstraintValidator.php

+     *
+     * @throws UnexpectedTypeException
+     */
+    final protected static function testConstraint(Constraint $constraint, string $expectedClass)


do we really need this? I feel like this removes some info for static analysis + increases the stack traces of exception for little practical benefit, don't you think?

I ran a little investigation:

PHPStorm doesn't understand this

Psalm does https://getpsalm.org/r/acd72ab0ab cc @muglug

PHPStan doesn't https://phpstan.org/r/be6b68a728fc1d24fb27069640f46701 cc @ondrejmirtes

Anyway Validator is full of this piece of code, so I think it's worth it. SA tools which don't support it is problem of the tool itself, not the code. And we can help them by specifying @param alongside @inheritDoc (works for PHPStorm and Psalm, PHPStan is stubborn like usual).

Extraction of common pieces of code is important for keeping consistency. Also, if this was done in the first place, there would be no need to manually touch so many places in #27917

But, this should be renamed. testConstraint is odd one. assertInstanceOf?

That's not really a common piece of logic - that's an "if"...

I didn't mention "logic", I mentioned "piece of code". Anyway "if" contains some logic. This "if" is in almost all validators. Devs keep producing highly repetitive code instead of extracting it to function. This is like no. 1 rule of programming. Programs are good at repeating, not humans.

And here is another advantage of having such thing there in the first place - if it was already there, all custom validators using such function would be automatically compatible with #27917. Since it's not there (because such function is too simple right?), every custom constraint will now have to change this piece of code within it. But it's too late for #27917. Maybe another time there will be need to change the message or exception type.

I get that, but I don't agree: designing the code to make such changes easy is not a target at all to me. Software architecture should be built around things that change, not those that don't (#27917 is not a change that should be centralized to me.)

gmponos · 2018-10-03T16:42:03Z

Not sure how much my word counts on this, but personally I don't like this. It's the mentality behind of it that I don't like.

I believe that it encourages developers to add more special cases inside these functions. What I mean is that I already imagine developers preparing their special cases with extra ifs to be added inside the toString function or developers developing a toXml function etc etc.

The testConstraint I can not imaging how a developer can come up with a special case but does it really worth it adding the function call overhead over there? And as @nicolas-grekas said it is just an if

Never the less if this gets approved I believe that the results returned by toString method is inconsistent. If the value is '' it will return null and this can cause some trouble to developers who might misused the function.

ro0NL · 2018-10-04T09:29:15Z

@gmponos i see you're point, im not too happy with the current approach myself as well :)

If the value is '' it will return null

That's intended, i.e. the current behavior. But i agree we might not want to standardize it like this, as not every constraint has to rely on it. FYI in core i'd like to get rid of this rule eventually, see #28611

I'll give this some more thought for now, and see how #27917 goes first.

nicolas-grekas · 2018-10-20T19:48:17Z

Shall we close here?

ro0NL · 2018-10-20T19:49:52Z

yep :) ill do a consistency round some other time per constraint

carsonbot added Status: Needs Review Validator Feature labels Sep 30, 2018

[Validator] Standardize constraint validators

7ec59ad

nicolas-grekas added this to the 4.2 milestone Oct 1, 2018

carsonbot removed the Status: Needs Review label Oct 1, 2018

OskarStark requested changes Oct 1, 2018

View reviewed changes

carsonbot added the Status: Needs Work label Oct 1, 2018

nicolas-grekas reviewed Oct 3, 2018

View reviewed changes

ro0NL mentioned this pull request Oct 4, 2018

[Validator] catch any UnexpectedValueException on validation #27917

Merged

ro0NL closed this Oct 20, 2018

ro0NL deleted the constraint-tests branch October 20, 2018 19:50

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Validator] Standardize constraint validators #28645

[Validator] Standardize constraint validators #28645

ro0NL commented Sep 30, 2018 •

edited

Loading

ostrolucky commented Sep 30, 2018

ro0NL commented Sep 30, 2018

ostrolucky commented Sep 30, 2018

gmponos commented Oct 1, 2018

OskarStark Oct 1, 2018

ro0NL commented Oct 2, 2018 •

edited

Loading

nicolas-grekas Oct 3, 2018 •

edited

Loading

ostrolucky Oct 3, 2018

nicolas-grekas Oct 3, 2018

ostrolucky Oct 3, 2018

nicolas-grekas Oct 3, 2018

gmponos commented Oct 3, 2018

ro0NL commented Oct 4, 2018 •

edited

Loading

nicolas-grekas commented Oct 20, 2018

ro0NL commented Oct 20, 2018 •

edited

Loading

[Validator] Standardize constraint validators #28645

[Validator] Standardize constraint validators #28645

Conversation

ro0NL commented Sep 30, 2018 • edited Loading

ostrolucky commented Sep 30, 2018

ro0NL commented Sep 30, 2018

ostrolucky commented Sep 30, 2018

gmponos commented Oct 1, 2018

OskarStark Oct 1, 2018

Choose a reason for hiding this comment

ro0NL commented Oct 2, 2018 • edited Loading

nicolas-grekas Oct 3, 2018 • edited Loading

Choose a reason for hiding this comment

ostrolucky Oct 3, 2018

Choose a reason for hiding this comment

nicolas-grekas Oct 3, 2018

Choose a reason for hiding this comment

ostrolucky Oct 3, 2018

Choose a reason for hiding this comment

nicolas-grekas Oct 3, 2018

Choose a reason for hiding this comment

gmponos commented Oct 3, 2018

ro0NL commented Oct 4, 2018 • edited Loading

nicolas-grekas commented Oct 20, 2018

ro0NL commented Oct 20, 2018 • edited Loading

ro0NL commented Sep 30, 2018 •

edited

Loading

ro0NL commented Oct 2, 2018 •

edited

Loading

nicolas-grekas Oct 3, 2018 •

edited

Loading

ro0NL commented Oct 4, 2018 •

edited

Loading

ro0NL commented Oct 20, 2018 •

edited

Loading