-
-
Notifications
You must be signed in to change notification settings - Fork 9.6k
NotBlank validator should not invalidate null values #27876
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
Comments
That would be a huge BC break. |
Maybe we could add a On a side note, I witnessed at least 10 Symfony projects where they declared a |
Can you provide a source for this? We always use just NotBlank. Usage for NotNull is really rare in projects I've seen.
How is "not blank" value ever null value? Blank includes null.
For what use case? |
@ostrolucky because there is a need to check for non null empty values. You can always argue that a form (for an API or not) - and I agree on paper. But in practice for a lot of front-ends omitting non provided fields as opposed to sending null requires too much work for what it's worth, hence this need in the back-end. |
If you have a text type field in your form and don't type anything there, it's transformed to null. If you omit that field completely, it's again null. There is no difference. This kind of problem is meant to be solved with validation groups. |
@ostrolucky I don't really see how that invalidates the points above tbh |
If I don't misunderstand the proposal that would pretty much the same as having the |
Provides the value is a string but NotBlank also works on other types
…On Sun 8 Jul 2018 at 20:46, Christian Flothmann ***@***.***> wrote:
If I don't misunderstand the proposal that would pretty much the same as
having the Length constraint with min set to 1, isn't it?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#27876 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AE76gXwgY2hK-pKQnpLUU9zMM-Y0c-0Pks5uElOMgaJpZM4VFUrc>
.
|
How do you use it with other types if you do not want to fail on |
No we do explicit casts in your blank validator. We don't rely on |
Well, my point is I don't see a use case for the |
@xabbuh : The issue with the
|
Which makes no sense to me neither tbh... |
You can also use NotEqualTo with '' |
@ostrolucky there is workarounds, we are not arguying otherwise. We would like however to make those constraints more intuitive |
Definitely agreeing with @theofidry . When using any Constraints in symfony the first rule is "Do not validate what you are not supposed to", so I don't understand why there is a We can always find a way to go around this of course. But to stay consistent with any other constraints I feel like |
I don't agree for one. You can't deprecate that without majority agreeing. All I see is loud minority. What you guys want can be achieved with other constraints like Length and NotEqualTo, what NotBlank does currently can't be replaced with any other single constraint, only with multiple. |
Again, we are not arguing we cannot achieve what we want. There is several workarounds available for them and we already discussed about them here. Our point is that the default behaviour is confusing and intuitive. That you consider it to be a loud minority and not a design/UX issue is another story and up for debate and why this issue has been created. |
Seems intuitive to me. Null is blank, NotBlank prevents blank values. |
I know this can be a huge debate but for me "the absence of value" does not mean "a blank value". Also |
Adding an option |
This is definitely an issue, especially as Rather than deprecating existing validators/constraints (
I had a little play with what that might look like and came up with the following that should cover most data types an API would receive. It probably needs tidying up a bit if anyone thinks this is a good idea. /**
* @Annotation
* @Target({"PROPERTY", "METHOD", "ANNOTATION"})
*/
class NotEmpty extends Constraint
{
public const IS_EMPTY_ERROR = '1034929d-a83b-4817-a722-0a4a9266067a';
protected static $errorNames = array(
self::IS_EMPTY_ERROR => 'IS_EMPTY_ERROR',
);
public $message = 'This value should not be empty, use null instead.';
public function validatedBy(): string
{
return NotEmptyValidator::class;
}
} class NotEmptyValidator extends ConstraintValidator
{
public function validate($value, Constraint $constraint)
{
if (!$constraint instanceof NotEmpty) {
throw new UnexpectedTypeException($constraint, NotEmpty::class);
}
if ($value === null
// Allow zero numerical values, etc.
|| (\is_scalar($value) && !\is_string($value))
// Pure whitespace counts as being empty?
|| (\is_string($value) && \trim($value, " \r\n\t") !== '')
) {
return;
}
if (empty($value) || (\is_string($value) && \trim($value, " \r\n\t") === '')) {
$this->context->buildViolation($constraint->message)
->setParameter('{{ value }}', $this->formatValue($value))
->setCode(NotEmpty::IS_EMPTY_ERROR)
->addViolation();
}
}
} |
Adding an |
…alues (dunglas) This PR was squashed before being merged into the 4.3-dev branch (closes #29641). Discussion ---------- [Validator] NotBlank: add a new option to allow null values | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes <!-- don't forget to update src/**/CHANGELOG.md files --> | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | #27876 | License | MIT | Doc PR | todo This PR adds a new option to the `@NotBlank` constraint to allow null values. As described in #27876, this is particularly useful when creating web APIs. Commits ------- 484d22a [Validator] NotBlank: add a new option to allow null values
…reject empty strings (ogizanagi) This PR was merged into the 4.4 branch. Discussion ---------- [Validator] Add a Length::$allowEmptyString option to reject empty strings | Q | A | ------------- | --- | Branch? | 4.4 <!-- see below --> | Bug fix? | no | New feature? | yes <!-- please update src/**/CHANGELOG.md files --> | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | N/A <!-- #-prefixed issue number(s), if any --> | License | MIT | Doc PR | Todo (change the warning on top of https://symfony.com/doc/current/reference/constraints/Length.html) which defaults to `true` in 4.4 but will trigger a deprecation if not set explicitly in order to make the default `false` in 5.0. While it could be solved now thanks to #29641 by using both `@Length(min=1)` & `@NotBlank(allowNull=true)` constraints, as expressed in symfony/symfony#27876 (comment) and following comments, the `@Length(min=1)` behavior doesn't match our expectations when reading it: it feels logical to invalidate empty strings, but it actually doesn't. Hence the proposal of making the behavior of rejecting empty strings the default in 5.0. In my opinion, the flag could even be removed later. Commits ------- e113e7f812 [Validator] Add a Length::$allowEmptyString option to reject empty strings
…reject empty strings (ogizanagi) This PR was merged into the 4.4 branch. Discussion ---------- [Validator] Add a Length::$allowEmptyString option to reject empty strings | Q | A | ------------- | --- | Branch? | 4.4 <!-- see below --> | Bug fix? | no | New feature? | yes <!-- please update src/**/CHANGELOG.md files --> | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | N/A <!-- #-prefixed issue number(s), if any --> | License | MIT | Doc PR | Todo (change the warning on top of https://symfony.com/doc/current/reference/constraints/Length.html) which defaults to `true` in 4.4 but will trigger a deprecation if not set explicitly in order to make the default `false` in 5.0. While it could be solved now thanks to #29641 by using both `@Length(min=1)` & `@NotBlank(allowNull=true)` constraints, as expressed in #27876 (comment) and following comments, the `@Length(min=1)` behavior doesn't match our expectations when reading it: it feels logical to invalidate empty strings, but it actually doesn't. Hence the proposal of making the behavior of rejecting empty strings the default in 5.0. In my opinion, the flag could even be removed later. Commits ------- e113e7f [Validator] Add a Length::$allowEmptyString option to reject empty strings
…reject empty strings (ogizanagi) This PR was merged into the 4.4 branch. Discussion ---------- [Validator] Add a Length::$allowEmptyString option to reject empty strings | Q | A | ------------- | --- | Branch? | 4.4 <!-- see below --> | Bug fix? | no | New feature? | yes <!-- please update src/**/CHANGELOG.md files --> | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | N/A <!-- #-prefixed issue number(s), if any --> | License | MIT | Doc PR | Todo (change the warning on top of https://symfony.com/doc/current/reference/constraints/Length.html) which defaults to `true` in 4.4 but will trigger a deprecation if not set explicitly in order to make the default `false` in 5.0. While it could be solved now thanks to #29641 by using both `@Length(min=1)` & `@NotBlank(allowNull=true)` constraints, as expressed in symfony/symfony#27876 (comment) and following comments, the `@Length(min=1)` behavior doesn't match our expectations when reading it: it feels logical to invalidate empty strings, but it actually doesn't. Hence the proposal of making the behavior of rejecting empty strings the default in 5.0. In my opinion, the flag could even be removed later. Commits ------- e113e7f812 [Validator] Add a Length::$allowEmptyString option to reject empty strings
…reject empty strings (ogizanagi) This PR was merged into the 4.4 branch. Discussion ---------- [Validator] Add a Length::$allowEmptyString option to reject empty strings | Q | A | ------------- | --- | Branch? | 4.4 <!-- see below --> | Bug fix? | no | New feature? | yes <!-- please update src/**/CHANGELOG.md files --> | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | yes <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | N/A <!-- #-prefixed issue number(s), if any --> | License | MIT | Doc PR | Todo (change the warning on top of https://symfony.com/doc/current/reference/constraints/Length.html) which defaults to `true` in 4.4 but will trigger a deprecation if not set explicitly in order to make the default `false` in 5.0. While it could be solved now thanks to #29641 by using both `@Length(min=1)` & `@NotBlank(allowNull=true)` constraints, as expressed in symfony/symfony#27876 (comment) and following comments, the `@Length(min=1)` behavior doesn't match our expectations when reading it: it feels logical to invalidate empty strings, but it actually doesn't. Hence the proposal of making the behavior of rejecting empty strings the default in 5.0. In my opinion, the flag could even be removed later. Commits ------- e113e7f812 [Validator] Add a Length::$allowEmptyString option to reject empty strings
Description
In most validators, there's a failsafe mecanism that prevent the validator from validating if it's a
null
value, as there's a validator for that (NotNull
). I thinkNotBlank
shouldn't bother onnull
values, especially asNotBlank
andNotNull
are used together to preventnull
values too.Not really a feature request, but not really a bug too... more like a RFC but for all versions. But I guess this would be a BC break though. :/ So maybe add a deprecated on the validator if it's a null value or something, and remove the
null
invalidation from theNotBlank
on 5.0 ?Currently, we need to reimplement the validator just to skip
null
values...Possible Solution
Either deprecate the validation on
null
value inNotBlank
, or do as in most validators, (ifnull
value, then skip). But as I mentionned, this would probably be a bc break.The text was updated successfully, but these errors were encountered: