Opened 7 years ago

Closed 7 years ago

#9623 closed (wontfix)

!ChoiceField widgets should never be empty

Reported by: bronger Owned by: nobody
Component: Uncategorized Version: 1.0
Severity: Keywords:
Cc: bronger@… Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


In oder to have valid HTML always, the widgets for ChoiceFields and its decendants, namely Select and MultipleSelect, should never be empty. Instead, they should show some dummy selection (e.g. "---------") with empty value, which is then evaluated in the clean method to the empty list.

Change History (3)

comment:1 Changed 7 years ago by kmtracey

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to invalid
  • Status changed from new to closed

No, widgets should not always have the dummy entry. If you are displaying a form for an existing object with an already-chosen value, or a new object where a default has been provided, then it is user-unfriendly to have the dummy entry in the list, since if for some reason the user chooses that entry, the form will not validate on submission. Why give the user an unnecessary path to encountering an error? In both of these cases valid html will be generated because there is a choice in the list that will be selected. If you have a case of the admin or valid application code producing invalid html then you need to include it -- the right fix is something other than making the widgets always have this dummy choice.

comment:2 Changed 7 years ago by bronger

  • Resolution invalid deleted
  • Status changed from closed to reopened

Sorry for re-opening it but I think you misunderstood me.

I didn't say that there should always be a dummy entry, I said that there should never be an empty selection. Thus, only if the choices attribute is empty, the dummy choice should be generated. Making the clean method properly, selecting it is like selecting nothing -- which should be what the user can expect. For example, my own field class says:

class MultipleUsersField(forms.MultipleChoiceField):
    def set_users(self, additional_users=[]):
        if not self.choices:
            self.choices = ((u"", 9*u"-"),)
    def clean(self, value):
        if value == [u""]:
            value = []
        value = super(MultipleUsersField, self).clean(value)
        return django.contrib.auth.models.User.objects.in_bulk([int(pk) for pk in set(value)]).values()

This way, you don't end up with invalid HTML.

comment:3 Changed 7 years ago by kmtracey

  • Resolution set to wontfix
  • Status changed from reopened to closed

I did misunderstand you (you didn't mention empty choices originally, so I took "empty" to mean the more common situation of an empty selection), but I still don't agree. The widget shouldn't be changing the choices value it is given; it is the responsibility of the code calling the widget to ensure the choices are valid. It's logically inconsistent for the widget caller to be responsible for adding (if conditions warrant) the "empty" choice in the case where there are some other choices but not in the case where there are no other choices. It's more consistent for the caller to always be responsible for adding (if conditions warrant) this "empty" entry, regardless how many other choices are in the list.

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