That's it! The binding.Bind function takes care of validating required fields.
By default, if there are any errors (like a required field is empty), binding middleware will return an error to the client and your app won't even see the request. To prevent this behavior, you can use binding.BindIgnErr instead.
Don't try to bind to embedded struct pointers; it won't work. See martini-contrib/binding issue 30 if you want to help with this.
Naming Convention
By default, there is one naming convention for form tag name, which are:
Name -> name
UnitPrice -> unit_price
For example, previous example can be simplified with following code:
If your struct doesn't implement binding.ErrorHandler, then default error handling will be applied. Otherwise, calls ErrorHandler.Error method to perform custom error handling.
Notes:
Your application (the final handler) will not even see the request if there are any errors when default error handling is applied.
Header Content-Type will be used to know how to deserialize the requests.
Don't attempt to bind a pointer to a struct. This will cause a panic to prevent a race condition where every request would be pointing to the same struct.
Form
binding.Form deserializes form data from the request, whether in the query string or as a form-urlencoded payload. It only does these things:
Note that it does not handle errors. You may receive a binding.Errors into your own handler if you want to handle errors.
MultipartForm and File Uploads
Like binding.Form, binding.MultipartForm deserializes form data from a request into the struct you pass in. Additionally, this will deserialize a POST request that has a form of enctype="multipart/form-data". If the bound struct contains a field of type *multipart.FileHeader (or []*multipart.FileHeader), you also can read any uploaded files that were part of the form.
Similar to binding.Form, no error handling is performed, but you can get the errors and handle them yourself.
Validate
binding.Validate receives a populated struct and checks it for errors with basic rules. It will execute the Validator.Validate() method on the struct, if it is a binding.Validator.
Validation Rules
There are some builtin validation rules. To use them, the tag format is binding:"<Name>".
Name
Note
OmitEmpty
Omit rest of validations if value is empty
Required
Must be non-zero value
AlphaDash
Must be alpha characters or numerics or -_
AlphaDashDot
Must be alpha characters or numerics, -_ or .
Size(int)
Fixed length
MinSize(int)
Minimum length
MaxSize(int)
Maximum length
Range(int,int)
Value range(inclusive)
Email
Must be E-mail address
Url
Must be HTTP/HTTPS URL address
In(a,b,c,...)
Must be one of element in array
NotIn(a,b,c,...)
Must not be one of element in array
Include(string)
Must contain
Exclude(string)
Must not contain
Default(string)
Set default value when field is zero-value(cannot use this when bind with interface wrapper)
To combine multiple rules: binding:"Required;MinSize(10)".
Customize Operations
Custom Validation
If you want additional validation beyond just checking required fields, your struct can implement the binding.Validator interface like so:
Now, any contact form submissions with "Go needs generics" in the message will return an error explaining your folly.
Custom Validation Rules
If you need to more validation rules that are applied automatically for you, you can add custom rules by function binding.AddParamRule, it accepts type binding.ParamRule as argument.
Custom validation rules are applied after builtin rules.
Custom Error Handler
If you want to avoid default error handle process but still want binding middleware calls handle function for you, your struct can implement the binding.ErrorHandler interface like so:
This operation happens after your custom validation.