Validators shouldn't fail when presence isn't required and value is missing

[tremby]

If I define a field which doesn't require a value (i.e. I'm not validating presence) but which has some other constraint such as a minimum string length, or it needs to be a member of a given set, if the value is not given I think the other validations should be skipped.

Otherwise every other validator needs a function attached which tests whether the value is present and if not gives the parameters for that particular validator. Or am I missing something?

[edubkendo]

If you set a minimum string length, and then leave the field blank, isn't the string actually shorter than the minimum length? That's probably why its failing. ie. the empty string is shorter than whatever length you set as a minimum.

[tremby]

I'd argue that null (which by saying you don't want to check for presence you are allowing as a valid value) isn't a string at all, and so the string length restrictions should not apply.

[thehydroimpulse]

@tremby An empty string isn't null but rather a string:

"" === null // false

So if you make a minimum length validation of 5, an empty string would pass. You would need an extra validation of presence and minimum length to pass.

[mildfuzz]

I think that there would be more use cases of people wanting to use a minimum string length as a presence validation that people who would need a minimum string validation to pass when empty.

I think @TheHydroImpulse has the right of it, a length range validation seems appropriate in this context.

[tremby]

Of course an empty string is not the same as null. I was not saying that.

1. The way I see it, if "presence" is required, null is not allowed but the empty string is. Null should fail validation, empty string and strings of any length should pass. (If no value at all was given, i.e. null was not passed explicitly, the default if there is one obviously takes effect.)
2. If you do not want to allow null or the empty string, but rather want to require a string at least 1 character long, you should validate both presence and a minimum length of 1. Now null fails, empty string fails, any string of 1 character or longer passes.
3. If you DO want to allow null OR an empty string and have them treated differently (this is a totally valid use case) you should not require presence and have no minimum string length. Now both no value at all (null) or an empty string should pass validation, as well as longer strings.
4. And now, my current requirement in the project I'm working on, if you DO want to allow null, or a string but that string must be two characters long, I want to validate a minimum and maximum string length of 2, but not presence. Null should pass validation, an empty string should fail, a string of length 1 should fail, a string of length 2 should pass and a string of length 3 or more should fail.

There are four different sets of requirements and all should be supported. It seems to me that treating "presence" as synonymous with "null not allowed" (which is what I assumed it did anyway) would solve this.

[tremby]

Was this resolved?

[thehydroimpulse]

@tremby Tower moved on to 0.5, which is a new codebase. 0.4 isn't being supported anymore.