Opened 8 years ago

Closed 8 years ago

Last modified 5 years ago

#8663 closed (wontfix)

Inconsistencies/Bug in ModelForm

Reported by: lingrlongr Owned by: nobody
Component: Forms Version: master
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: UI/UX:


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.

from django.db import models

  (0, 'Zero'),
  (1, 'One'),

class MyModel(models.Model):
  my_field = models.IntegerField(choices=MY_CHOICES)
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>

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>

This value doesn't appear in the 2nd case:
<option value="" selected="selected">---------</option>


Change History (4)

comment:1 Changed 8 years ago by ElliottM

Triage Stage: UnreviewedDesign decision needed

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?

comment:2 Changed 8 years ago by gkelly

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 Changed 8 years ago by Malcolm Tredinnick

Resolution: wontfix
Status: newclosed

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.

comment:4 Changed 5 years ago by Jacob

milestone: 1.0

Milestone 1.0 deleted

Note: See TracTickets for help on using tickets.
Back to Top