Suggestion for library improvement about ozzo-validation HOT 19 CLOSED

Thank you for your suggestions!

The usage design of Joi looks very neat to me. I will see how we can borrow some of its ideas here.

I totally agree with you about your comments on &c.Name instead of "Name". I have come up with a solution and will find time to implement it.

Regarding goburrow and other similar validation packages in golang, the main thing I don't like is that they rely on struct tags to define validation rules. It seems handy initially, but will quickly go out of control (hard to debug, error prone when working with many rules, hard to extend). It is also the main reason behind this package.

from ozzo-validation.

For the goburrow library, I was suggesting to refactor and incorporate the logic of the validations that the library has and convert it to your library format, not to use tags. It would enhance the already great built-in capabilities of your library. Thank you!

from ozzo-validation.

I see. Could you list which validators in goburrow may be considered?
For string/array length validation, we already have the Length validator.
And for numeric min/max validation, we have the Range validator.

from ozzo-validation.

Here is my recommendation. If the goburrow min, max, and notEmpty validations are refactored and incorporated into go-ozzo, you could eliminate the following validations in go-ozzo.

• Range
• Length
• NotNil

The elegance of the goburrow implementation is that the min and max validation apply to all data types including arrays, maps, slices, strings, and all types of integers and floats. Thus, one validation rule rules them all for min. Similarly for the max and notEmpty validations. In go-ozzo, you need to apply a range which is not intuitive if you only want to check the min or only the max value.

In the go-ozzo Range validation, I see the following comment:
Note that the value being checked and the boundary values must be of the same type.
In goburrow, the value being checked and the boundary values do not need to be of the same type.

With the goburrow implementation, if you want to check a range, you provide both the min and the max value. If you only want to check the min, you only apply the min validation. And so on...

The go-ozzo implementation for NotNil has the following comment:

NotNil only handles types including interface, pointer, slice, and map. All other types are considered valid.

Whereas the goburrow notEmpty validation rule applies to arrays, maps, slices, strings, and all types of integers and floats.

I just think the goburrow implementation is very elegant. However, I did not like the tag based validation, thus my suggestion to refactor it into the go-ozzo way of doing the validation.

from ozzo-validation.

If we could refactor the goburrow validation rules into go-ozzo and change the field names from being a string to a pointer, I think this would be the best library out there for validations!

from ozzo-validation.

One other suggestion I would like to make is that there should be an option to use the json struct tag field names instead of creating a new validation tag. This would save a lot of typing.

from ozzo-validation.

goburrow's notEmpty validator is equivalent to ozzo's Required validator. See more details here for why ozzo also provides a NotNil validator.

One other suggestion I would like to make is that there should be an option to use the json struct tag field names instead of creating a new validation tag. This would save a lot of typing.

"For example, you may set validation.ErrorTag to be "json" if you want to reuse the JSON field names as error field names."

from ozzo-validation.

Oh, I did not realize that. That works! Thanks!

from ozzo-validation.

I realized that if we want to use &c.Name instead of "Name" when declaring validation rules, we still need to specify a field name to receive the potential validation error (e.g. to serialize the validation errors of a struct, you would want to have a map of errors, each associated with a field name).

If such a error map is not desired, you may readily use Rules to validate field values.

from ozzo-validation.

We do need an error map. Can we use reflect just to get the field name? That way we can do away with a string field name and catch any errors during compile time. I personally use the json field names as my application is an api and I need to send back error messages for the same field names as they came in.

from ozzo-validation.

from ozzo-validation.

I have a similar library here, it's not publically available, but I can tell that we indeed use pointers instead of field names. And you can totally extract the name if you pass in the pointer to the struct itself as well. So, something like:

valid.Validate(&a).
  Mandatory(&a.FirstName, valid.MaxLength(250)).
  Mandatory(&a.LastName, valid.MaxLength(250)).
  Mandatory(&a.Email, valid.Email).
  Optional(&a.Age, valid.PositiveInteger).
  Done()

This way you can simply scan the struct at &a and create a map of all field addresses. Using that map you can lookup each individual field when necessary. Also you can ensure that all fields were visited by a validator - very important feature. In our case struct usually is a JSON input struct, so we extract field names from struct tags for error reporting.

Very nice library btw.

from ozzo-validation.

@nsf Any reason your library is not publicly available? Apart from go-ozzo, there is nothing like this out there and your library would generate more ideas on how to improve validation without using tags.

from ozzo-validation.

It's part of a proprietary project.

from ozzo-validation.

I use the chi library router for my applications. In talking about validation and suggesting the go-ozzo library to the author of the chi library, they have commented that they are developing a non-tag based and very simple library for request and response payloads validation for chi/render. Can't wait to see what they come up with. I believe they are waiting for Golang 1.8 to be released before they will publish the validation library, but I am not sure.

from ozzo-validation.

@nsf Thank you for your comments! The idea you described is very clever. I really like it and will try to implement it here. Thanks!

@msaron Regarding request/response payload handling, my other project ozzo-routing takes this way and can be readily used together with ozzo-validation.

from ozzo-validation.

I have implemented the new struct validation syntax: https://gist.github.com/qiangxue/580c98c1f59e97849bc8b626c2d3245e. Could you take a look before I commit it? Thanks.

from ozzo-validation.

@qiangxue Just a feedback on how I am planning to use your library. As mentioned above, I am coming in from a NodeJS background where I was using the hapijs/joi library for all my validations, but your library is even more powerful than that because it allows me to dynamically inject valid values based on the userid in the request.

I am creating a middleware where I am going to pass a map[requestInput string]interface{} to each request that I want to validate and which implements your validate() method. The requestInput keys will be one of the following types:

• headers
• query
• params
• payload (or body)
• auth

The middleware will process the validation for each input. The request handler will only be called if all validations pass. This ensures that when the request reaches the handler, you can rest assured that everything is clean and validated. For each input that has been processed by the middleware, it will inject that struct into the context so that it is available to the handler.

If you want to create this type of middleware for ozzo-routing, let me know and I will use the one you create. I am just coming in to golang and your implementation will be far better and more robust than mine.

from ozzo-validation.

@msaron Thank you for your compliments. I'm glad this library is useful for you. Your middleware idea sounds great to me. It should be very useful. I'm not sure if I will create this one for ozzo-routing. It's easy to create one specifically for a project, but to create a generic solution it involves quite some effort. If you have a first version, I will be more than happy to take a look and see how it may be generalized. Thanks.

from ozzo-validation.