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

[brantley]

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.

[Adrian Holovaty]

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.

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

[Adrian Holovaty]

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

[Adrian Holovaty]

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?

[Brantley <deadwisdom@…>]

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

[James Bennett]

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.

[Jacob]

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

[Brantley]

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.

[Alex Gaynor]

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

[(none)]

Milestone post-1.0 deleted

[Mikhail Korobov]

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

[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?