Validator Version 4

[adamwaite]

Validator was originally written when I was learning Swift (Swift 2) and has been adapted for Swift 3 and Swift 4. Now feels like a good time to update the code to honour the latest SDKs and Swift conventions.

Goals:

1. Eliminate that horrible Objective-C run time stuff.

2. Make the ValidationResult a monoid and follow functional programming conventions over those dodgy merge style methods.

3. More 'Swifty' APIs where possible.

4. Add CI support with Travis.

[anelad]

Do not forget to fix #113, it is a widely used rule. Actually, I'm not sure why you use generics in the first place; this is a text field, its input type will be String one or the other way.

P.S. I would like to work with you in this. You might contact me at [email protected] if you like.

[adamwaite]

Make the ValidationResult a monoid and follow functional programming conventions over those dodgy merge style methods. Can't transform empty values in the validation enum.

[adamwaite]

TODO:

• Eliminate that horrible Objective-C run time stuff (fixing Retain Cycles #78 in the process)
• Fix ValidationRuleRequired is not working #113
• Travis
• swift-package

[rodscoutinho]

Just a thought for version 4, sometimes when using the validate function you also need to get a list of rules which validation succeeded on, not just errors. For example: if I input "qwerty" as my password and I have 3 rules, length x 8, uppercase x 1, lowercase x 1, I might display to the user 2 rules as error messages, but also show that they have satisfied the lowercase condition. Under a text field it would look like this:

---

|qwerty |

---

✅at least one lowercase
❌at least one uppercase
❌at least 8 characters

This becomes harder to do unless individual models are returned with validation status, or if in addition to errors we also received unused errors or something to that effect.
Maybe version 4 can address this?

[piv199]

Do not forget to fix #113, it is a widely used rule. Actually, I'm not sure why you use generics in the first place; this is a text field, its input type will be String one or the other way.

P.S. I would like to work with you in this. You might contact me at [email protected] if you like.

Actually, I use validator quite a lot without UI and therefore validation for numbers are quite useful.

Btw, What I didn't like is coupling between error and message.

[anelad]

@piv199, then a separate number validation should be implemented. But "textview" says it's a UI for text. It's input is string in the first place. To make the code more flexible, trashing the scope is not a good idea.

For the coupling between error and message, I do not understand what you really mean. What I understand is the need of creating custom Error's with messages. If it is what I understand, there is no better and basic approach since Swift's Error is an interface without any initializers or etc.