Opened 18 years ago
Closed 11 years ago
#3111 closed New feature (wontfix)
newforms: Add as_tr(), as_li() methods to BoundField
Reported by: | brantley | Owned by: | Ashutosh 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 by , 18 years ago
Summary: | Newforms needs as_tr(), as_li() for fields → newforms: Add as_tr(), as_li() methods to BoundField |
---|
comment:2 by , 18 years ago
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 by , 18 years ago
But you couldn't override as_tr()
on your field class, because as_tr()
would be on BoundField
, not on Field
...
comment:4 by , 18 years ago
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 by , 18 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:6 by , 18 years ago
I certainly think it would. The flexibility this adds is quite remarkable once you start using it.
comment:7 by , 17 years ago
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 by , 17 years ago
Triage Stage: | Design decision needed → Accepted |
---|
If it's good enough for Adrian, it's good enough for me :)
comment:9 by , 17 years ago
Owner: | changed from | to
---|---|
Status: | new → 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 by , 17 years ago
Owner: | removed |
---|---|
Status: | assigned → new |
comment:11 by , 17 years ago
These can also make simple helper methods for the as_ul() and as_table() methods.
comment:12 by , 16 years ago
milestone: | → post-1.0 |
---|
comment:14 by , 14 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:15 by , 14 years ago
Severity: | normal → Normal |
---|---|
Type: | enhancement → New feature |
comment:16 by , 13 years ago
Easy pickings: | unset |
---|---|
UI/UX: | unset |
Is django really going to have even more html generated in python?
comment:17 by , 11 years ago
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 by , 11 years ago
Resolution: | → wontfix |
---|---|
Status: | assigned → closed |
Good idea! Ideally we'd reuse some of the HTML generation in
Form.as_ul()
andForm.as_table()
, but I'm not sure whether that can be done elegantly.