Skip to content

[Validator] Deprecate use of Locale validation constraint without setting "canonicalize" option to true #26075

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Feb 20, 2018

Conversation

phansys
Copy link
Contributor

@phansys phansys commented Feb 7, 2018

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

See #22353 (comment).

public function __construct($options = null)
{
if (!($options['canonicalize'] ?? false)) {
@trigger_error('"canonicalize" option with value `false` is deprecated since Symfony 4.1 and will be removed in 5.0. Use "canonicalize"=>true instead.', E_USER_DEPRECATED);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The .... Set it to true instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I took as example the syntax at Email::__construct(). Updated.

@@ -30,7 +30,7 @@ class LocaleValidator extends ConstraintValidator
public function validate($value, Constraint $constraint)
{
if (!$constraint instanceof Locale) {
throw new UnexpectedTypeException($constraint, __NAMESPACE__.'\Locale');
throw new UnexpectedTypeException($constraint, Locale::class);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

unrelated, should be reverted to ease merger's job

);
}

/**
* @dataProvider getInvalidLocales
*/
public function testInvalidLocales($locale)
public function testInvalidLocales(string $locale)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be reverted to ease merger's job

@phansys phansys force-pushed the locale_validator branch 2 times, most recently from 3d1d2d2 to d465dbd Compare February 11, 2018 12:12
@phansys
Copy link
Contributor Author

phansys commented Feb 11, 2018

Comments addressed.

@phansys
Copy link
Contributor Author

phansys commented Feb 12, 2018

@fabpot, @nicolas-grekas; should we consider valid a locale including variants? "it_IT_NEDIS_ROJAZ_1901" by instance: http://php.net/manual/en/locale.getallvariants.php

@nicolas-grekas
Copy link
Member

should we consider valid a locale including variants?

Only if a real world app needs it. Let's not spend time on theoretical improvements.

@phansys
Copy link
Contributor Author

phansys commented Feb 12, 2018

I can't imagine a practical use case using variants right now, but I think we should left a note about the situation in docs, explaining that locales including variants will not be considered valid. WDYT?

@phansys
Copy link
Contributor Author

phansys commented Feb 16, 2018

Do you know how we could avoid having different results per platform? AppVeyor is reading "en-us.utf8@VARIANT" as a valid locale, while in Travis it is invalid. Shouldn't both environments be using the same bundled ICU data?

@nicolas-grekas
Copy link
Member

Shouldn't both environments be using the same bundled ICU data?

let's make the test case independent from the data version instead, we're not testing the data set here.

public function __construct($options = null)
{
if (!($options['canonicalize'] ?? false)) {
@trigger_error('The "canonicalize" option with value `false` is deprecated since Symfony 4.1 and will be removed in 5.0. Set it to `true` instead.', E_USER_DEPRECATED);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we just merged a PR that removes all occurences of "and will be removed in 5.0."
would you mind removing them from this PR please?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure! Done ;)

Copy link
Member

@fabpot fabpot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

made some minor comments

public function __construct($options = null)
{
if (!($options['canonicalize'] ?? false)) {
@trigger_error('The "canonicalize" option with value `false` is deprecated since Symfony 4.1. Set it to `true` instead.', E_USER_DEPRECATED);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Instead of backticks, you should use ", and make one sentence;

The "canonicalize" option with value "false" is deprecated since Symfony 4.1, set it to "true" instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Message updated. Thank you.

public function testNullIsValid()
/**
* @group legacy
* @expectedDeprecation The "canonicalize" option with value `false` is deprecated since Symfony 4.1. Set it to `true` instead.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't forget to change those expectations.

Copy link
Member

@fabpot fabpot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

after the double-dots are removed

public function __construct($options = null)
{
if (!($options['canonicalize'] ?? false)) {
@trigger_error('The "canonicalize" option with value "false" is deprecated since Symfony 4.1, set it to "true" instead..', E_USER_DEPRECATED);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

double-dot :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry. Fixed.

@fabpot
Copy link
Member

fabpot commented Feb 20, 2018

Thank you @phansys.

@fabpot fabpot merged commit 1572540 into symfony:master Feb 20, 2018
fabpot added a commit that referenced this pull request Feb 20, 2018
…raint without setting "canonicalize" option to `true` (phansys)

This PR was merged into the 4.1-dev branch.

Discussion
----------

[Validator] Deprecate use of `Locale` validation constraint without setting "canonicalize" option to `true`

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

See #22353 (comment).

Commits
-------

1572540 Deprecate use of `Locale` validation constraint without setting "canonicalize" option to `true`
@phansys phansys deleted the locale_validator branch February 20, 2018 19:53
javiereguiluz added a commit to symfony/symfony-docs that referenced this pull request Feb 23, 2018
…` validation constraint (phansys, javiereguiluz)

This PR was merged into the master branch.

Discussion
----------

[Validator] Add docs for "canonicalize" option at `Locale` validation constraint

Related to symfony/symfony#22353, symfony/symfony#26075.

Closes #7660.

Commits
-------

14f10bc Final changes
4c28e1f Minor changes
0cc4ee8 Add docs for "canonicalize" option at `Locale` validation constraint
@emodric
Copy link
Contributor

emodric commented Apr 4, 2018

Maybe I'm missing something, but how can setting canonicalize to false be deprecated in 4.1, when that option didn't even exist in 4.0?

https://github.com/symfony/symfony/blob/4.0/src/Symfony/Component/Validator/Constraints/Locale.php
https://github.com/symfony/symfony/blob/4.0/src/Symfony/Component/Validator/Constraints/LocaleValidator.php

@stof
Copy link
Member

stof commented Apr 4, 2018

hmm, deprecating a value of the option at the same time it is added looks indeed weird, as it means we cannot write code running both on 4.0 and on 4.1 without deprecation

@phansys
Copy link
Contributor Author

phansys commented Apr 4, 2018

Because the deprecation is not about using the option itself, but about passing false as value for it (which is allowed to keep BC with the default behavior present until 4.1).

@emodric
Copy link
Contributor

emodric commented Apr 4, 2018

@phansys But the option didn't exist before 4.1, therefore you couldn't even pass false to it?

@stof
Copy link
Member

stof commented Apr 4, 2018

@emodric but omitting it is equivalent to passing false as this is the default in 4.x (for BC reasons)

@phansys
Copy link
Contributor Author

phansys commented Apr 4, 2018

Right @emodric, this option will be introduced in 4.1, and the deprecation will be thrown if you omit it or if you pass false as value for it.

@emodric
Copy link
Contributor

emodric commented Apr 4, 2018

Okay, I understand, but:

as it means we cannot write code running both on 4.0 and on 4.1 without deprecation

How to solve this case that @stof mentions, or should we check for kernel version to avoid the deprecation?

@phansys
Copy link
Contributor Author

phansys commented Apr 4, 2018

Except a build matrix executing same build for both versions, I can't imagine which scenario could require avoid the deprecation without changing the codebase triggering it. But I think there is no way to use this validator without deprecation in ^4.1 if you don't follow the upgrade path. ^4.0.0 will not trigger any deprecation at all, since this feature will not be backported at all (AFAIK).

@emodric
Copy link
Contributor

emodric commented Apr 4, 2018

Build matrix discovered this deprecation for me, yes. No worries, I will add a @legacy annotation to the test :)

Thanks for your help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants