Hi, I would like to add support for gin binding to use the UnmarshalText method from the Golang standard encoding.TextUnmarshaler interface. Since UnmarshalText is a Golang standard, many major enterprises and Golang developers have it defined for their structs, which reduces developer effort significantly.
I am aware of this PR that adds support for gin's own custom BindUnmarshaler interface, but this is not a scalable solution across the entire Golang ecosystem. Most companies that offer Golang-specific tooling do not define this interface, and it is not practical for us to change our company's codebase just to redefine our own custom type everywhere we want to use gin's own interface. In contrast, many companies do offer support for Golang standard interfaces like UnmarshalText and UnmarshalJson, which we can integrate seamlessly only if gin adds support for UnmarshalText.
There are already other users complaining about this same issue with gin:
so this is not limited to just me.
To prevent backwards-compatibility issues, we can add a new opt-in-only config option to the gin.Engine struct such as UseEncodingTextUnmarshalerForBinding bool. If this config option is active, then gin will use the TextUnmarshal method by default when unmarshalling custom types.
Note: My use case involves MongoDB with their primitive.ObjectID type, which is a custom type representing [12]byte. I am unable to bind it through uri nor query parameter, even though the type already has UnmarshalText defined.
Hi, I would like to add support for gin binding to use the
UnmarshalTextmethod from the Golang standardencoding.TextUnmarshalerinterface. SinceUnmarshalTextis a Golang standard, many major enterprises and Golang developers have it defined for their structs, which reduces developer effort significantly.I am aware of this PR that adds support for gin's own custom
BindUnmarshalerinterface, but this is not a scalable solution across the entire Golang ecosystem. Most companies that offer Golang-specific tooling do not define this interface, and it is not practical for us to change our company's codebase just to redefine our own custom type everywhere we want to use gin's own interface. In contrast, many companies do offer support for Golang standard interfaces likeUnmarshalTextandUnmarshalJson, which we can integrate seamlessly only if gin adds support forUnmarshalText.There are already other users complaining about this same issue with gin:
so this is not limited to just me.
To prevent backwards-compatibility issues, we can add a new opt-in-only config option to the
gin.Enginestruct such asUseEncodingTextUnmarshalerForBinding bool. If this config option is active, then gin will use theTextUnmarshalmethod by default when unmarshalling custom types.Note: My use case involves MongoDB with their
primitive.ObjectIDtype, which is a custom type representing[12]byte. I am unable to bind it through uri nor query parameter, even though the type already has UnmarshalText defined.