Opened 3 years ago

Closed 3 years ago

#33437 closed New feature (wontfix)

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

Reported by: Christophe Henry Owned by: nobody
Component: Forms Version: 4.0
Severity: Normal Keywords:
Cc: Hrushikesh Vaidya Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Change History (4)

comment:1 by Hrushikesh Vaidya, 3 years ago

Cc: Hrushikesh Vaidya added

comment:2 by David Smith, 3 years ago

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.

comment:3 by Christophe Henry, 3 years ago

#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.

comment:4 by Carlton Gibson, 3 years ago

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top