!ChoiceField widgets should never be empty

[Torsten Bronger]

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.

[Karen Tracey]

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.

[Torsten Bronger]

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.

[Karen Tracey]

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.