<p>What do you use for HTML Form ?
Even for a simple form we need to render it, validate it and bind it to Go struct. It's not very difficult but very boring. So, I wonder how do you do ?</p>
<p>I found only one package which seems to do everything :
<a href="https://github.com/bluele/gforms">https://github.com/bluele/gforms</a>
But I don't know if it's idiomatic as it doesn't seems a lot of dev are using it.</p>
<p>Any advice ?</p>
<hr/>**评论：**<br/><br/>neoasterisk: <pre><p>When writing web apps, I usually implement the API in Go which accepts JSON and manually validates the fields server side. </p>
<p>The forms only exist on the client side and any additional validation happens using HTML and Javascript.</p></pre>H1Supreme: <pre><p>This is the most sensible answer. The number of front end javascript frameworks is in the trillions now, so I won't bother to suggest one in particular.</p>
<p>Write you're backend API in Go, and use an already well equipped .js frontend framework to handle forms. This is pretty much standard for most sites being built.</p></pre>m3wm3wm3wm: <pre><blockquote>
<p>and use an already well equipped .js frontend framework to handle forms.</p>
</blockquote>
<p>What do you mean by that? Any frontend validation needs to be backed by backend validation too. This requires implementing and maintaining the logic twice.</p></pre>earthboundkid: <pre><p>Realistically though, the only way not to double validation is to either a) not validate on the client (which is a bad UI) or b) use isomorphic JavaScript, which means Node plus a million tons of glue code frameworks. </p></pre>jmank88: <pre><p><a href="http://www.gorillatoolkit.org/pkg/schema">http://www.gorillatoolkit.org/pkg/schema</a></p>
<p>"Package gorilla/schema fills a struct with form values."</p></pre>lion_rouge: <pre><p>+1 for gorilla/schema</p></pre>: <pre><p>[deleted]</p></pre>m3wm3wm3wm: <pre><blockquote>
<p>My advice is to do it by hand and that's all.</p>
</blockquote>
<p>I see many valid questions about the basics of web developments in this sub. Here are my observations:</p>
<p>(1) The questions are really valid: How do I build an HTML form in Go with binding and validation? This is not 1996, the user expects an obvious short answer in the first google result. And that answer is <em>not</em> expected to be: do it manually.</p>
<p>(2) The most voted answer is most likely like the above: do it manually. In this case, hardcode the validation logic for every field of every form, and repeat it all over again when you start a new web project.</p>
<p>I have a very mixed feeling about Go web development. Its simplicity, performance and anti-framework approach is seductive. But when it comes to actual implementation, many voices in my head tell me this cannot be the right thing to do, maybe I'm using the wrong tool for webdev, which in this case boils down to the wrong language.</p></pre>: <pre><p>[deleted]</p></pre>m3wm3wm3wm: <pre><blockquote>
<p>Just map and validate those damned fields and move on..</p>
</blockquote>
<p>You're missing the point.</p>
<p>You only mentioned the easy part: Validation itself is easy, it's nothing but a bunch of if/else statements. Anyone can do that and 'move on', leaving a shitload of spaghetti code as the legacy.</p>
<p>What is hard is <em>where</em>, <em>when</em> and <em>how</em> to validate. Should it be in the handler, or in the database model? What if you have a web view, and a json api? How would you share the validation between the form handler, and the api handler?</p>
<p>There is no such a thing as writing and 'moving on' in real world projects... unless you are a consultant who gets paid to finish a contract milestone. By all means, hardcode the shit of the validators, and 'move on' to you next easy project. Do not feel bad for the next programmer dealing with you shitty legacy.</p>
<blockquote>
<p>your next project will very probably have a different data structure and/or mapping & validation needs.</p>
</blockquote>
<p>... > 99% of web projects follow the same form validation implementations, if one exists. Such implementation does no exist in Go. It does exists in many other static/dynamic languages.</p></pre>VirmundiUndead: <pre><p>I'm just learning Golang. Is Go the wrong language for web development (probably), or is the philosophy around Go wrong for web development? </p>
<p>In Java, you'd pick from a myriad of frameworks. Each provides some form of binding. This is handy, but none solve a full trip worth of validation. </p></pre>karnd01: <pre><p>Nobody's answer is going to be wrong, it all depends on your use case but here are a couple of packages that may aid in the development time.</p>
<p><a href="https://github.com/go-playground/form" rel="nofollow">https://github.com/go-playground/form</a>
<a href="https://github.com/go-playground/validator" rel="nofollow">https://github.com/go-playground/validator</a></p></pre>1Gijs: <pre><p>A similar project that I found:
<a href="https://godoc.org/github.com/kirves/go-form-it" rel="nofollow">https://godoc.org/github.com/kirves/go-form-it</a></p>
<p>I think what is still missing in Go is a tool that generates a basic CRUD web-application from a database. Enter the db credentials and bang, the app generates front-end html forms plus back-end Go code to see lists, create / edit / delete records. All very basic, but it would really save a lot of people a lot time. The generated files (.go, .tmpl, some basic .css) can then be used for further improvement and refinements.</p>
<p>Always useful for creating and admin interface or maybe as a base for a larger application.</p>
<p>Something like for example forestadmin.com does. They add a lot of extra features and services, but basically it does just generates a node app that offers a CRUD application.</p>
<p>For the future maybe the tool can work with templates itself, so the generated output could be simple html, basic Bootstrap plus other themes.</p>
<p>I case someone here needs a project to fill the holidays ;-)</p></pre>earthboundkid: <pre><p>Have you seen <a href="https://github.com/blue-jay/blueprint" rel="nofollow">Bluejay</a>?</p></pre>gavbaa: <pre><p>I've made some modifications to the bluele/gforms project and had some of my own changes rolled in. It does make a couple of unusual decisions in form building idiomatically, but it's not completely wrong either. As far as capturing how either django-forms or wtforms does it, it seems to have missed the mark somewhat, or at least isn't thorough in the approach. In part this is a limitation of Go itself (metaclasses what now?), but in part I think the library just hasn't had enough development on it. I've already got a <a href="https://github.com/gavbaa/gforms/tree/using" rel="nofollow">fork</a> with some new field types and additional validation support for form-wide validators, and am considering breaking it off into a new project to take another stab at the overall data structures, improve access to validation and so on, the same challenges you're struggling with.</p></pre>hobbified: <pre><p>For rendering forms: just write the damn HTML in a template. There have been innumerable attempts to do better, in hundreds of languages, and all of them have been more work than they're worth, in my opinion. Similarly for validation: there are some useful helper functions that you can either find, or write yourself, as appropriate, but for the most part the rule is just "write code to validate data at the point where it needs to be valid". Trying to formalize and automate it doesn't save anyone from writing code, it just makes them write code in an unexpressive, inflexible language invented for the validator.</p>
<p>For binding values, <a href="https://godoc.org/github.com/robfig/bind" rel="nofollow">github.com/robfig/bind</a> works well, and <a href="https://echo.labstack.com/" rel="nofollow">echo</a> also has a binder that does a good job. Echo's supports something that I've had to do manually in the past, which is to choose based on Content-Type whether to bind as JSON, XML, or multipart/form-data, which is nice if you want to use the same endpoint for both "web" and "API" personalities, which is a pattern I very much like for certain kinds of apps. You can structure things similarly to how you would for a single-page app hitting an API, except without the single-page app nonsense.</p></pre>
