#8663 closed (wontfix)
Inconsistencies/Bug in ModelForm
Reported by: | lingrlongr | Owned by: | nobody |
---|---|---|---|
Component: | Forms | Version: | dev |
Severity: | Keywords: | ModelForm forms | |
Cc: | Triage Stage: | Design decision needed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
When a ModelForm is used to display a form for a Model, the fields defined with a choices option insert a "-------" value for the first option when the form is rendered. If you override a field and manually specify the choices for a Select widget, this "-------" does not appear as the first choice.
# models.py from django.db import models MY_CHOICES = ( (0, 'Zero'), (1, 'One'), ) class MyModel(models.Model): my_field = models.IntegerField(choices=MY_CHOICES)
# forms.py from django import forms from myapp.models import MyModel, MY_CHOICES class MyModelForm(forms.ModelForm): #my_field = forms.IntegerField(widget=forms.Select(choices=MY_CHOICES)) class Meta: model = MyModel
View the HTML for the form with my_field commented out:
>>> from myapp.forms import MyModelForm >>> f = MyModelForm() >>> print f <tr><th><label for="id_my_field">My field:</label></th><td><select name="my_field" id="id_my_field"> <option value="" selected="selected">---------</option> <option value="0">Zero</option> <option value="1">One</option> </select></td></tr>
Now uncomment my_field in MyModelForm:
>>> from myapp.forms import MyModelForm >>> f = MyModelForm() >>> print f <tr><th><label for="id_my_field">My field:</label></th><td><select name="my_field" id="id_my_field"> <option value="0">Zero</option> <option value="1">One</option> </select></td></tr>
This value doesn't appear in the 2nd case:
<option value="" selected="selected">---------</option>
SVN-8643
Change History (4)
comment:1 by , 16 years ago
Triage Stage: | Unreviewed → Design decision needed |
---|
comment:2 by , 16 years ago
The Select widget choices must be passed to it, which is exactly what the ModelForm does when it creates the Select widget, only it takes the liberty of adding a default, or empty_label. The Select widget doesn't know anything about the field it is representing, and thus cannot derive the choices from it.
I believe if the user wants to declare a widget that they should have full control, and the Select widget currently does that; it displays exactly the choices that it's given and doesn't involve itself in adding a default option. A ModelForm is more intelligent and has access to the necessary data to derive whether or not a default choice should be added.
It may be "inconsistent", but I like the way it is. There's no reason to override a widget if the automatic one does exactly what's desired.
comment:3 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
After thinking about this a bit and trying out a couple of alternatives, I think gkelly's summary is a fairly accurate statement of affairs. If you're controlling things down to the level of the form widget, it's up to you to pass in the choices you want: widgets display exactly what you give them.
It would be nice in some cases to make it completely replaceable in the way tried in the report, but it would be confusing and require working around in other cases. So let's leave it as it is.
What happens if someone wants to specify their own "unset" display value rather than the default dashes? What happens to everyone who create their own default? What if someone doesn't want a default at all?