-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Convert "ID", "URL", ... to lowercase in templates #18
Comments
Or use the way we have right now, which needs an intermediary step converting first to a |
Another option added to the list: an interface with a method that returns the data.Map. Any struct that wants to change the map can implement that function, like json.Marshaler does in the standard library. |
Both of those ideas seem like good ones. (initialisms and a data.Marshaler interface) |
Yes, they're not exclusive. Minimum surprise when using common names like ID or URL in structs and a way of going further and use custom ways of serializing the data when needed. I'll take a look into it next weekend to prepare a pull request and see what is needed (or if you prefer to do it I'll leave it to you) |
Sure, I'm open to a PR. Thanks! |
I would actually like similar functionality and just made PR #19 to add the Marshaler side of things. Would you be open to a small code generator/validator that could could warn users of possible gotchas when run over a given package (i.e. it could display the fact that you have a field called ID but in the data map, without implementing Marshaler, it will be iD)? |
@ttacon If we convert them directly they don't need warnings (perhaps for initialisms not included in the golint list?) |
@ernestoalejo I entirely agree, my comment was more aiming for newer users who are just starting to use soy. Something along the lines of "give tool a package to inspect, identify what objects ever get passed to tofu.Render, data.New (etc) and then let them know if any of their structs contain initialisms." That way, if there was some confusion/frustration trying to identify what values where accessible inside a soy template, it could be extremely useful in illuminating where those frustrations were arising from. Not a essential tool, just a fun concept. |
@ttacon It's an interesting idea, although I think it's difficult (if I'm using a map[string]interface{} for the data or things like that). Anyway more static analysis tools to prevent or flag human errors it's always a good thing. |
This is more an open question to discuss it. Should the library convert to lowercase common initialisms when they are at the start of a field name? Right now it uses only the first letter and it returns "iD" and "uRL".
We could also use the struct field tag to allow custom names when converting to data.Map.
The text was updated successfully, but these errors were encountered: