Comments (10)
So basically you're proposing adding the Type field? The others are already there.
from schema.
Yep
from schema.
Would it really be that much more helpful? You already get the key name so can just look up the struct definition.
from schema.
I guess I can get the field type that way by using reflection but it's just extra work and I also need to manage some caching for those types to improve performance. But it's all OK. Feel free to close the issue.
from schema.
I guess my question is about the usefulness of having the type name in the error message. For the programmer it seems it would be enough to have the field name. Or do you have some other purpose in mind, where your program would inspect the type?
from schema.
Yes, I've a wrapper func that parses the form to given struct and does some validation afterwards. Finally it returns an err next to the list of invalid fields. Since I use a wrapper func to avoid extra work on each http handler, I wouldn't manually check the struct to see the type of invalid fields and therefore I can't produce specific error messages for that types.
e.g.:
type User struct {
Age int `schema:"age" validate:"max:30"`
Time time.Time `schema:"time"`
}
var user User
invalids, err := parseForm(r.Form, &user)
if err != nil {
w.WriteHeader(http.IntervalServerError)
return
}
// some possible values of `invalids`
// if all valid
map[string]string{}
// if age field is not an int
map[string]string{
"age": "must be a number", // parsing err
}
// if age over 30 and time is not valid
map[string]string{
"age": "must be greater than 30", // validation error
"time": "time must be UTC formatted", // parsing err
}
// then I can simply response a json error message to user:
errRes := struct {
Message string
Fields map[string]string
}{"Unvalid form data", invalids}
json(w, http.StatusBadRequest, errRes)
from schema.
right, but you wouldn't just return the type string to the user since it could be any arbitrary go type? It seems to me it wouldn't have much meaning to a client of a web service
from schema.
of course, I never return the go type as a json error response. I produce pretty error messages depending on those types in my API and send them as a response. For example if I expect a field as a UTC time and it can not being parsed to time.Time I simply say "this field is not a valid time" or a field's value expected as a bool but given value doesn't satisfy strconv.ParseBool() then I say "this field is not bool"
from schema.
by the way the Type that I talking about in ConversionError is the expected type of the field
from schema.
Right. I guess one complication is what to return in the cases of slice elements and how to differentiate between the error being a slice not passed as the value, or one of the elements being the wrong type..
from schema.
Related Issues (20)
- [bug] Required check bypassed if there is another field whose prefix is the field HOT 3
- [question] Unable to decode slice of structs HOT 1
- [feature] New release/tag HOT 1
- [feature] default values for scheme struct fields HOT 13
- [feature] Use json struct tags if wanted HOT 2
- [question] "+" symbol HOT 6
- ⚠️ The Gorilla Toolkit is Looking for a New Maintainer HOT 10
- [bug] Unstable decoding of different keys that are case-folded to the same value HOT 1
- Not checking for nil might lead to nil pointer dereference HOT 4
- [question] Error converting into []byte or []uint8 HOT 2
- [bug] schema: converter not found for Page, when the struct name is same with field name. HOT 6
- [question] Why can't Encoder check and call fmt.Stringer.String() on element automatically? HOT 1
- [BUG] v1.2.0 Cannot decode into slice of strings HOT 2
- [bug] need to skip unexported field HOT 1
- [BUG] Nested struct with required field is not failing on decode HOT 1
- [FEATURE] Documentation HOT 4
- [Question] Is ignoring mismatched slice element types intended behavior? HOT 3
- [BUG] panic in 1.3.0 HOT 6
- [Question] Form encoding/decoding ignores slice of struct HOT 3
- [BUG] Slice encoding drops empty values rather than encoding them as `nil` or default
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from schema.