Opened 9 years ago

Closed 14 months ago

#3111 closed New feature (wontfix)

newforms: Add as_tr(), as_li() methods to BoundField

Reported by: brantley Owned by: aashu_dwivedi
Component: Forms Version:
Severity: Normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

A great function to add to fields would be "as_tr()" and "as_li()", it would render
just one row of the form table, as well as the corresponding error if
needed. It's very useful when you want to specially
define the layout of a specific field, but you want the rest to be
default. Otherwise if you want to define just one field, then you
have to define them all.

Change History (18)

comment:1 Changed 9 years ago by adrian

  • Summary changed from Newforms needs as_tr(), as_li() for fields to newforms: Add as_tr(), as_li() methods to BoundField

Good idea! Ideally we'd reuse some of the HTML generation in Form.as_ul() and Form.as_table(), but I'm not sure whether that can be done elegantly.

comment:2 Changed 9 years ago by Brantley <deadwisdom@…>

Yes, that would be ideal. Especially since you could over-ride the as_tr() method on your class, and then not have to change the as_table() method.

comment:3 Changed 9 years ago by adrian

But you couldn't override as_tr() on your field class, because as_tr() would be on BoundField, not on Field...

comment:4 Changed 9 years ago by adrian

To implement this, we'd have to add an as_tr() hook to Widget, not BoundField, because client code never deals with BoundField classes directly. The basic Widget.as_tr() method would look something like this:

    def as_tr(self, label, rendered):
        # 'rendered' is the result of widget.render()
        return u'<tr><th>%s</th><td>%s</td></tr>' % (label, rendered)

Then Form.as_table() would call this, and we'd have to add as_p() and as_li() methods to Widget to mirror as_p() and as_ul() on the Form.

Would it be worth it?

comment:5 Changed 9 years ago by adrian

  • Triage Stage changed from Unreviewed to Design decision needed

comment:6 Changed 9 years ago by Brantley <deadwisdom@…>

I certainly think it would. The flexibility this adds is quite remarkable once you start using it.

comment:7 Changed 8 years ago by ubernostrum

I'd personally be -1 on this; the use case presented is custom presentation, and default methods are never going to be able to handle the entire slippery slope of one-off custom cases people will want, so I'd say the solution is to just do the form presentation yourself in the template, or override a form-level method like as_table to omit the single field you want to present specially.

comment:8 Changed 8 years ago by jacob

  • Triage Stage changed from Design decision needed to Accepted

If it's good enough for Adrian, it's good enough for me :)

comment:9 Changed 8 years ago by deadwisdom

  • Owner changed from nobody to deadwisdom
  • Status changed from new to assigned

Ubernostrum, you cad! Of course it's not going to be able to handle the entire slippery slope, but this cuts it in half and handles much of it. It's really a pain when you have a long form and need to customize just one field. This makes it much simpler, and is an elegant solution.

comment:10 Changed 8 years ago by deadwisdom

  • Owner deadwisdom deleted
  • Status changed from assigned to new

comment:11 Changed 8 years ago by Alex

These can also make simple helper methods for the as_ul() and as_table() methods.

comment:12 Changed 7 years ago by kratorius

  • milestone set to post-1.0

comment:13 Changed 6 years ago by anonymous

  • milestone post-1.0 deleted

Milestone post-1.0 deleted

comment:14 Changed 4 years ago by aashu_dwivedi

  • Owner set to aashu_dwivedi
  • Status changed from new to assigned

comment:15 Changed 4 years ago by lrekucki

  • Severity changed from normal to Normal
  • Type changed from enhancement to New feature

comment:16 Changed 3 years ago by kmike

  • Easy pickings unset
  • UI/UX unset

Is django really going to have even more html generated in python?

comment:17 Changed 14 months ago by loic84

I agree with @kmike, HTML in python is technical debt that we should fix, adding more as_method() feels counterproductive.

This is an 8 years old ticket, I propose we close it, any objections?

comment:18 Changed 14 months ago by aaugustin

  • Resolution set to wontfix
  • Status changed from assigned to closed
Note: See TracTickets for help on using tickets.
Back to Top