Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Change validation to consider the empty string a valid value #1482
This appears to be the default assumption of our users. The empty string can now be validated with regexes and other checks. Additionally non-browser users and form elements without any value at all can now be considered during validation.
I actually ran into this in os-autoinst/openQA#2812 where we have an API which accepts an optional parameter that must be numeric or empty. If the empty string is given, the value is cleared. Other values can be updated without changing or clearing said value, however - so empty is not the same as undefined. I actually defined it as
tl;dr Voting yes
It seems to trip new users up quite a bit. Perhaps it is because it looks like you are asserting whether the topic has to be part of the input or can be omitted, but it is actually considering the value as well (which is really what the checks are for).
This change introduces a clearer separation between "is the topic in the input" and "does the value of the topic meet this criteria" (e.g. is not an empty string). It also makes using Mojolicious::Validator nicer to use outside of validating web forms (like validating CSV files from crazy systems that have unstable headers!) where an empty string in a required topic is valid.
Any code currently using
My vote is yes because having
Doesn't this get messy as an interface when you have an optional value that is allowed to be the empty string, but if it is not then extra requirement.
Seems messy if everything then has to go though regex
I agree on the old setup
optional('field') -> size(3,10)
was annoying because field was undef it it had no value, but the requirement worked if the field had a value.
I agree with daleif. How do I handle the case that e.g. I expect an optional number. The browser always transmits an empty input field as empty string.
In this minimal example I always get has_error for an optional param. That doesn't seem right.
So just returning
(one question, not 100% related, are a check allowed to change the value passed on? I had a check that verifies a date (input via a string like 2020-03-21) and it seemed convenient to just replace the input with the generated DateTime object)