You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
modelScheme = {
"name": {
set: function() {},
get: function() {},
validators: [
new LengthValidator(6, 'Name is too short.'),
new MatchValidator('nameConfirm', 'Name and its confirmation should match.')
]
}
Also, i have a question about current validation model. Why it uses Exceptions for validation? It would be better to return boolean or a "SetResult" object from setter, wouldn't it?
For example in such a way:
{accepted: boolean,validationErros: ['Name is too short','Name and its confirmation should match']}
Of cource, this idea is affected by validators concept, but it may be useful. What's your appenion?
P.S. Just thinking if it is better to implement it in a concrete application or should it be useful for your framework :)
The text was updated successfully, but these errors were encountered:
I've gotten a couple of questions about using errors for validation. The reason I went with using errors is because I believe they are the most flexible. You can mix your validation logic with your formatting. I wanted the set function to be as simple as taking in the input and returning the output rather than having to check for errors. I also believe that having it throw an error allows chaining of validators and setters. Because you can have the validators in the setter you can also do some initial formatting before validation (such as strip whitespace).
So if you want to stipr whitespace then have a validator that looks for length, one that makes sure it's all letters and then a setter that converts the string to something else you could compose them altogether like:
function (str) {if (str.length > 64) throw new validationError('too long'); return str;}
I like the idea of being able to have an array of all the validation errors and perhaps splitting out validation. I should be able to put somethilng like that in without changing the setting logic so you can choose to put validations in your setter or put them separate.
What about adding validators to a model scheme?
It could look like this:
Also, i have a question about current validation model. Why it uses Exceptions for validation? It would be better to return boolean or a "SetResult" object from setter, wouldn't it?
For example in such a way:
Of cource, this idea is affected by validators concept, but it may be useful. What's your appenion?
P.S. Just thinking if it is better to implement it in a concrete application or should it be useful for your framework :)
The text was updated successfully, but these errors were encountered: