Repository navigation
ngMinlength and ngMaxlength attribute not bind value, when model value is type Number #5936
Description
cdc4d48#diff-c244afd8def7f268b16ee91a0341c4b2R514
I was reading the commit above, and i have a question...
In the previous code, if the 'value' was type Number, the '.length' property return 'undefined'. So instead of go in the 'if' condition, go in the 'else'.
But in this new condition 'ctrl.$isEmpty(value) || value.length', if the 'value' is a Number, then the condition will return false. Then the validation wont pass. But in the previous condition the same case pass correctly.
My question is: This behavior was intentional? Because i understand if i want a field with a number value i can use input type="number" and then use the 'min' and 'max' attributes. But the layout that i get for this type of input is different in each browser, and some times doesnt fit in the design of the app.
If i am right, i can submit a pull request do help with this, but first i have to be sure that this behavior wasnt intentional.
This example uses Angular 1.2.7 and will success the validation:
http://plnkr.co/edit/YRpqT6Dwc6xbe2LYHEwq
This example uses Angular 1.2.8 and will fail the validation: http://plnkr.co/edit/rZgEtjyDuErDro9K94Q3
The same will apply for 'maxlength' attribute.
Activity
caitp commentedon Jan 23, 2014
This is a dupe of a number of issues/pull requests like #1588... I'm going to mark this for 1.3 but I can't guarantee that this will be implemented
vitorlopez commentedon Jan 23, 2014
I don't believe that's the same case. In my exemple the the new expression return a different value than the previous condition.
I think this is a honest mistake, because if you look this condition (that is the current):
is the exactly opposite of this (that is the legacy)
But before it was in a if else statement. Now is simply returning itself.
This causes the bug that i mentioned.
I think that's not what the other issue you mentioned means.
I don't want the parameter takes expressions. I want the input value can be type Number and still bind correctly.
If you look at the 2 examples that i put at Plunker, you see this behavior.
My first try would be change the current expression to:
This works, but is ugly. But explains my point.
caitp commentedon Jan 23, 2014
Ok, thanks for the clarification
fix(input): ngMinlength/ngMaxlength should not invalidate non-stringl…
fix(input): ngMinlength/ngMaxlength should not invalidate non-stringl…
fix(input): ngMinlength/ngMaxlength should not invalidate non-stringl…
fix(input): ngMinlength/ngMaxlength should not invalidate non-stringl…
caitp commentedon Sep 25, 2014
This has been fixed in the master branch, but it looks like stable branch still has issues. I'll see if this can be fixed in stable
caitp commentedon Sep 25, 2014
So this does work on stable (I'm not sure which commit fixed it), but there aren't really any test cases or anything.
What doesn't work is the attribute is not observed the way it is in the master branch, so the validation only happens during parsing/formatting, not just when the attribute value changes.
I think I'm not going to push extra tests because I don't want stable to diverge unnecessarily from master, but yeah this works
caitp commentedon Sep 25, 2014
hmm... but the plunker doesn't do what you expect in v1.2.25... sigh :( looking again
fix(input): format as string before running minlength/maxlength forma…
fix(input): always format viewValue as a string inputs with text cont…
fix(input): always format viewValue as a string inputs with text cont…
caitp commentedon Sep 25, 2014
Closed by 1b8b41a