Export struct sliceValidateError to allow error casting

[edebernis]

This PR allows to cast error returned by ShouldBindWith functions when input parameter is a slice.

[kszafran]

@appleboy @thinkerou Can we get this merged? I also found myself needing this. Without it, I have to iterate over slices manually, so that I can access the individual validation errors.

[daheige]

@kszafran I strongly support the proposal of this function and hope it can be integrated into the trunk.

…

------------------ Original ------------------ From: kszafran ***@***.***> Date: Fri,Aug 6,2021 5:35 PM To: gin-gonic/gin ***@***.***> Cc: heige ***@***.***>, Comment ***@***.***> Subject: Re: [gin-gonic/gin] Export struct sliceValidateError to allow error casting (#2777) @appleboy @thinkerou Can we get this merged? I also found myself needing this. Without it, I have to iterate over slices manually, so that I can access the individual validation errors. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[edebernis]

@appleboy @thinkerou Any chance to get this merged ? Thanks !

[appleboy]

need @thinkerou's approval.

[kszafran]

I would actually advice against merging this. I have an alternative idea and could contribute a PR. I'm playing with it right now, validator has a method called Var ((*validator.Validate).Var(...)), which can take a slice or an array. If we use it instead of exposing a custom error type, then all errors returned by bindings will be consistent.

I'm also adding a feature allowing configuring validation tags for map/slice types.

[kszafran]

Here is a proof of concept. Registering type tags is similar to registering struct-level validators:

var typeTags = make(map[reflect.Type]string)

// RegisterTypeTag registers a validator tag for a map or slice type. For example:
//     infra.RegisterMapTag(api.MyMap{}, "gt=3,dive")
// where api.MyMap is a map type, e.g.
//     type MyMap map[string]int
// If you register a tag, you have to include "dive" to validate map/slice elements.
func RegisterTypeTag(typ interface{}, tag string) {
	// TODO panic if the type is not one of: Slice, Array, Map
	typeTags[reflect.TypeOf(typ)] = tag
}

type defaultValidator struct {
	once     sync.Once
	validate *validator.Validate
}

var _ binding.StructValidator = &defaultValidator{}

func (v *defaultValidator) ValidateStruct(obj interface{}) error {
	if obj == nil {
		return nil
	}

	value := reflect.ValueOf(obj)
	switch value.Kind() {
	case reflect.Ptr:
		return v.ValidateStruct(value.Elem().Interface())
	case reflect.Struct:
		return v.validateStruct(obj)
	case reflect.Slice, reflect.Array, reflect.Map:
		if tag, ok := typeTags[value.Type()]; ok {
			return v.validateVar(obj, tag)
		} else {
			return v.validateVar(obj, "dive")
		}
	default:
		return nil
	}
}

func (v *defaultValidator) validateStruct(obj interface{}) error {
	v.lazyinit()
	return v.validate.Struct(obj)
}

func (v *defaultValidator) validateVar(obj interface{}, tag string) error {
	v.lazyinit()
	return v.validate.Var(obj, tag)
}

func (v *defaultValidator) Engine() interface{} {
	v.lazyinit()
	return v.validate
}

func (v *defaultValidator) lazyinit() {
	v.once.Do(func() {
		v.validate = validator.New()
		v.validate.SetTagName("binding")
	})
}

The benefits are:

1. you always get the same kind of error, whether you validate struct, slice, or map
2. you get map validation (not possible currently)
3. you can define custom tags for top-level slices and maps, for example:

binding.RegisterTypeTag(MyMap{}, "dive,keys,gt=5,endkeys,dive")

This allows you to validate top-level map keys (not possible currently), as well as top-level slices (also not possible):

binding.RegisterTypeTag(MySlice{}, "gt=4,dive")

If we merge this PR and export SliceValidationError, then clients will obviously start to depend on it, and we won't be able to implement this solution, which is more consistent and powerful in my opinion.

[kszafran]

I can create a PR tomorrow. I can also see if I could implement contextual validation: #2741

[kszafran]

Here you go: #2877 @appleboy @thinkerou

[kszafran]

I have reworked my implementation. It's now more similar to the existing sliceValidateError: #2877

[SubhramRana]

hbvjhbjhbh

[thinkerou]

lgtm