Repository navigation
Conversation
|
I've been thinking about this some more. What is the use case that makes the |
|
Bumping this. It seems to me like a real issue that needs to be dealt with. Would be great to get some feedback on this... |
There was a problem hiding this comment.
I talked with @matsko about this in a8c7cb8#commitcomment-6681109 and the consensus is that there should be initial validation. So maybe this can dropped later. And I don't think it's not even that bad, as the modelController sets these odd values itself.
There was a problem hiding this comment.
okay, I'll remove the WIP comments and tidy this up then.
|
One example for re-running validation is some sort of constraint. If A is true, then B can be 8 characters long, but if A is false, then only 4. Then you need to change the validator on B and re-run it. Or do you mean something else? |
|
Yes, but I was thinking that I'm not sure that this behavior is really required many times in real life. My general feeling was that developers will usually prefer to reset the value in B themselves once A is changed instead of letting angular re-validate. Never mind, I'm probably wrong about that. |
|
This fix is really important when you want to do cross field validation. I'm having lots of issues trying to implement min-date/max-date validation in a datepicker. At the minute, when you $setViewValue of a value that validates to false against another property on the scope the value is set to undefined. However, if the property that validates against changes and you rerun the validators (via $validate()) the error is cleared and the field is set to $valid but the value stays as undefined. |
|
@shahata - I think it is important if you have asynchronous validation of any kind. Imagine a validator that looks up a value in a server. Only when the response arrives would you know if the field is valid or not. |
There was a problem hiding this comment.
Could we make this more clear $$setModel -> $$writeModelToScope ?
If `$validate` is invoked when the model is already invalid, `$validate` should pass `$$invalidModelValue` to the validators, not `$modelValue`. More over, if the model has become valid, the previously invalid model should be assigned to `$modelValue`. Lastly, in case the model has become invalid, the previously valid model should be assigned to `$$invalidModelValue`. Closes #7836
There was a problem hiding this comment.
just as a quick note, this is less code if you say scope.$apply("max = 1"), and easier to read. I wouldn't worry about assignment expressions being removed from the grammar, that's not going to happen.
If `$validate` is invoked when the model is already invalid, `$validate` should pass `$$invalidModelValue` to the validators, not `$modelValue`. Moreover, if `$validate` is invoked and it is found that the invalid model has become valid, this previously invalid model should be assigned to `$modelValue`. Lastly, if `$validate` is invoked and it is found that the model has become invalid, the previously valid model should be assigned to `$$invalidModelValue`. Closes angular#7836 Closes angular#7837
If
$validateis invoked when the model is already invalid,$validateshould pass$$invalidModelValueto the validators, not$modelValue. More over, if the model has become valid, the previously invalid model should be assigned to$modelValue. Lastly, in case the model has become invalid, the previously valid model should be assigned to$$invalidModelValue.Closes #7836