Add possibility to render fields individually using as_p, a_table and as_ul

[Christophe Henry]

Currently, to render a form, there is a choice between rendering the form entirely with:

  <form action="/your-name/" method="post">
    {% csrf_token %}
    {{ form }}
    <input type="submit" value="Submit">
  </form>

and the more cumberstone solution of ​Rendering fields manually if you need more flexibility — for instance if you need to fieldsets like proposed in #6630:

  <form action="/your-name/" method="post">
    {% csrf_token %}
    {{ form }}
    
    <div class="fieldWrapper">
      {{ form.subject.errors }}
      {{ form.subject.label_tag }}
      {{ form.subject }}
    </div>
    
    <input type="submit" value="Submit">
  </form>

What I propose is a tradeoff where field can be rendered individually using this simple syntax:

  <form action="/your-name/" method="post">
    {% csrf_token %}
    {{ form }}
    
    {{ form.subject.as_p }}
    
    <input type="submit" value="Submit">
  </form>

I opened ​a proposition PR to solve this feature request.

[David Smith]

Thank you for your proposal. I have a few comments (mainly concerns, sorry) on this.

The first is that the current as_ methods are not recommended due to accessibility concerns see #32339. I don't think we should be adding additional features to something that we are not willing to recommend, even if we stop short of removing the due to backward compatibility concerns. Having said that it could be appropriate if an as_div() render style is introduced.

I wonder about having the same named functions on both the field and the form. I'd have thought that would lead to some confusion?

I appreciate this is about whole forms rather than fields is I wonder how far the new template based form rendering API could meet this need.

[Christophe Henry]

#32339 mentions discouraging developers from using <fieldset> and <legend>, which is the main purpose for this proposition. That begin said, I get there's not much point in proposing as_ul and as_table for fields. I'm opened to suggestions.

[Carlton Gibson]

Hi Christophe. Thanks for the proposal.

I think this would be too much API, for little benefit. As David says, leaning towards the new template based form rendering is the way to go, and we're looking at deprecating the various as_p() &co methods.

If you wanted this kind of this, and the inbuilt rendering isn't enough for you, I'd look towards third-party packages (such as Crispy Forms, Floppy Forms, Django Sniplates, ...and so on) , or adding a custom tag taking a form field to your own project. (I hope one of those options helps :)

Thanks again.