Opened 18 years ago
Closed 17 years ago
#4237 closed (wontfix)
newforms form_for_model ignores radio_admin
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Forms | Version: | dev |
Severity: | Keywords: | ||
Cc: | Triage Stage: | Design decision needed | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Building off of ticket #3268 if you specify radio_admin=True the newforms form_for_model shortcut should display the field as a radioselect field.
Attachments (2)
Change History (9)
by , 18 years ago
Attachment: | radio_select.diff added |
---|
comment:1 by , 18 years ago
Component: | Uncategorized → django.newforms |
---|---|
Has patch: | set |
Owner: | changed from | to
comment:2 by , 17 years ago
Needs tests: | set |
---|---|
Triage Stage: | Unreviewed → Accepted |
Seems fair enough. Just needs some tests.
by , 17 years ago
Attachment: | radio_select_with_tests.diff added |
---|
Patch now with tests and documentation.
comment:3 by , 17 years ago
Needs tests: | unset |
---|---|
Triage Stage: | Accepted → Ready for checkin |
Looks good
comment:4 by , 17 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
No, we don't want to do this. It's adding an attribute to model fields that is only for presentational control. Presentation information does not belong in data models.
If you want this sort of control and still want to use form_for_model(), then use the formfield_callback attribute to control things.
comment:5 by , 17 years ago
Resolution: | wontfix |
---|---|
Status: | closed → reopened |
Maybe I'm missing something, but radio_admin
is already an attribute of model fields:
http://www.djangoproject.com/documentation/model-api/#radio-admin
What's the attribute getting added?
comment:6 by , 17 years ago
Triage Stage: | Ready for checkin → Design decision needed |
---|
Logically, radio_admin should go away in newforms-admin. Just like prepopulate_from, it only exists for admin presentational purposes. Adding in a new feature that depends on it will mean people get attached to (and write code that depends on) a feature that should be on death row.
Still inclined to wontfix, but I'll "design decision" it for the time being and worry about it later.
comment:7 by , 17 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Agreeing with Malcolm, but going ahead with the wontfix; the "radio_admin" feature is going away.
use RadioSelect widget if radio_admin=True