add support to tag isvalid

[peczenyj]

Fixes Or Enhances

This Pull Requests adds a new tag called isvalid

If the field is marked with the validator tag isvalid, the type must implement the interface Validate() error and the return must be nil to be considered valid

A possible use case is: when dealing with Enumerations, the type can support a method Validate() error to check if the value is in specific the range defined. If we use enumer it generates a IsA<Type>() bool method that can be used to verify if the enumeration is valid or not, instead force the oneof tag (that needs to be always updated when we add one new value.

I wrote a pull request to add a Validate method on enumerations here and the interface Validate() error seems pretty common.

It may clash with existing tags that people may register, this is something that I don't know how to solve.

Make sure that you've checked the boxes below before you submit PR:

• Tests exist or have been written that cover this particular change.

@go-playground/validator-maintainers

[coveralls]

coverage: 74.254% (+0.01%) from 74.241%
when pulling 1cd3439 on peczenyj:add-support-to-tag-valid
into 8592022 on go-playground:master.

[nodivbyzero]

How does this isvalid differ from custom validators?
https://pkg.go.dev/github.com/go-playground/validator/v10#hdr-Custom_Validation_Functions

validator/_examples/custom-validation/main.go

Line 11 in 2cce309

String string `validate:"is-awesome"`

[tizu69]

How does this isvalid differ from custom validators? pkg.go.dev/github.com/go-playground/validator/v10#hdr-Custom_Validation_Functions

validator/_examples/custom-validation/main.go

Line 11 in 2cce309

String string `validate:"is-awesome"`

This seems more like a utility validator, and I'm all for it. It allows custom validators without ever touching reflection yourself, and instead having the library do the heavy lifting. The developer using isvalid just returns an error if they notice the struct is bad, and thats it. Benefit would also be that this may work with other validators if they adapt it.

[nodivbyzero]

The isvalid tag seems somewhat vague in its intent. Without a clear definition, it may be unclear how it interacts with other validation mechanisms, especially since different users might interpret it differently.
Would love to hear others’ thoughts as well!
cc: @chipaca, @deankarn, @alob-mtc @zemzale

[deankarn]

The isvalid tag seems somewhat vague in its intent. Without a clear definition, it may be unclear how it interacts with other validation mechanisms, especially since different users might interpret it differently.
Would love to hear others’ thoughts as well!
cc: @chipaca, @deankarn, @alob-mtc @zemzale

I agree I don't love the tag name especially because I could foresee a future similar validation added where the function signature is IsValid() bool which this tag would be more appropriate for, love the rest of the PR and it's intent thought, I have no issues there.

WDYT about validateFn or validateIface something to denote it's doing a validation from external code?

[tizu69]

validateFn sounds good to me

[peczenyj]

Sorry guys I just lost this entire discussion,

I have one clear motivation: if I have a custom validator, lets say is-a-valid-xxx-enumeration, and I am using in a library, I have to expose this custom validator as a public function (for instance) AND use it each time I need to include the structure that have this is-a-valid-xxx-enumeration or it will fail and that can be... tedious. and if I forget in one place (imagine a lib that include another, etc) I may have a problem in runtime if I don't add sufficient tests. Of course, it is not impossible, but tedious.

also, if I have several enumerations, I end up with several custom validators. Or I can use a generic one. That is my motivation

last the oneof tag is useful for string types, not for enumerations based on integers/ uint8 (like the ones generated by some tool like enumer)

so I can rename it to validateFn (or validateMethod) is everyone agrees

[zemzale]

Love the PR, the only thing I would add is a negative test that it doesn't panic when the type doesn't implement the validate function.

It's not required, but would help to ensure that interface conversions are not throwing panics.

[nodivbyzero]

Approved.

It would be beneficial to add a new example to showcase the functionality. While unit tests are valuable, having both a unit test and an example is even better ;)