A way to render a separate field
See original GitHub issueIn many cases it is easier to render the form manually in the template file. Consider a simple form:
var form = forms.create({
q: forms.fields.string()
});
form.handle(req, {
other: function (boundForm) {
...
I want to render that field in my template in a custom hand-crafted layout. Supposedly, form.fields.q.toHTML() and boundForm.fields.q.toHTML() should render the input field only (with the pre-filled submitted value in latter case), but instead they render the entire line with unwanted extra tags:
<div class="field"><label for="id_q">Q</label><input type="text" name="q" id="id_q" /></div>
You can take a look on the degree of freedom in Django forms engine: https://docs.djangoproject.com/en/dev/topics/forms/#customizing-the-form-template
Issue Analytics
- State:
- Created 10 years ago
- Comments:21
Top Results From Across the Web
Render fields separately in HTML QuickForm2 - Stack Overflow
I have been working on a form made using HTML_QuickForm2 in Symfony and I only know to render and display the entire form...
Read more >Blender 2.8 Tutorial: View Layers and Render ... - YouTube
... effects to characters separately, blurring the background and foreground layers separately for depth of field, or rendering different ...
Read more >How do I render a field twice with two different field formatters?
So in drupal 7 you could use: $output = field_view_field('node', $node, 'field_foo', array('type' => 'some_formatter', 'settings' => array(.
Read more >Render Django Form Fields Manually - GeeksforGeeks
This article revolves around how to render the form fields manually. Rendering Form fields manually. Illustration of Rendering Django Forms ...
Read more >View Layers — Blender Manual
Per collection you can adjust the way how the render engine needs to render the objects inside. Based on the render engine different...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Technically that’s correct, and I was a little exaggerating.
But if there were a method that simply emits a naked input (a shortcut for
boundField.toHTML(null, function(name, field, options) { return field.widget.toHTML(name, field) })
), that would be suited for any of those top 10 sites out of the box, without any need for creating “widgets”, and readily available for the division of labor between the backend node.js developer and the no-so-qualified guy that does the HTML cut and puts<input>
's where they belong.95% of the form fields in the actual web sites do not conform to what
boundField.toHTML()
emits, and never will. 99% of the forms do not conform to whatform.toHTML()
emits, and never will. Basically we have a default which is only useful for prototyping and academic use, and we are forced to jump through hoops for any real work (involving commercial-grade design and HTML cut), while there is an obvious simple method which would allow to avoid any of that work and keep the code clean, simple, readable and supportable.@ljharb, let me put it this way: if rendering a naked input field widget is to be treated as a rare edge case (as you seem to believe), indeed there is already a (rather twisted) way to achieve it.
My point is that rendering a naked input widget should be the default behaviour of
boundField.toHTML()
(instead offorms.render.div
), or at least have a sane-looking built-in shortcut. What you suggest — repetitive use ofboundField.toHTML(null, function(name, field, options) { return field.widget.toHTML(name, field) })
for every field — is beyond of being acceptable for such a frequent use case as creating a form with custom layout.Of course, this only relates to individual fields, not the form as a whole. How
form.toHTML()
currently works is just fine so not sure why you were giving it as example.form.toHTML()
is basically a prototyping/repetitive use shortcut anyway, in real life projects there’s little chance that the actual forms don’t get customized in this way or another.If you as a library maintainer do not see any sense in this, then yes, please simply consider my case solved.