Trovato questo perché la mia convalida era corretta, ma la classe ng-invalid
era ancora applicata perché ng-invalid-parse
veniva applicato.
Nel mio caso (semplice) Ero Convalida un indirizzo IPv4, e semplicemente non era riuscito a restituire il valore:
angular.module('insightApp.directives').directive('ipInput', function() {
return {
restrict: 'A',
require: '?ngModel',
link: function (scope, elem, attrs, ctrl) {
if (!(ctrl)) {
return;
}
function ipValidator(ngModelValue) {
if (
ngModelValue != '0.0.0.0' &&
ngModelValue != '255.255.255.255' &&
ngModelValue.match(/\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b/)
) {
ctrl.$setValidity('ipValidator', true);
} else {
ctrl.$setValidity('ipValidator', false);
}
// Adding this return statement resolved the problem with "ng-invalid-parse" being added
return ngModelValue;
}
ctrl.$parsers.push(ipValidator);
}
}
});
fonte
2016-01-26 01:56:03
Sì. Ma non sono riuscito a trovare lo stesso comportamento nel plunker allegato alla pagina dei documenti angolari. http://plnkr.co/edit/gRtAwHXo1bBGtsdNoVcq?p=preview – user2568304
Questo comportamento è stato aggiunto in 1.3 angular. Il suddetto plunk utilizza una versione precedente, quindi l'errore di analisi non è riproducibile. – user2568304