Using choices in a mode field forces use of TypedChoiceField in a form field

[Joey Wilhelm]

For most field types, I can override the class used to display the field with:

def formfield(self, **kwargs):
    defaults = {'form_class': CustomFormField}
    defaults.update(kwargs)
    return super(MyFieldClass, self).formfield(**defaults)

However, the Field class specifically overrides this when the field has 'choices'.
Lines 311-326 of django/db/models/fields/init.py contain the offending code. The specific override is on line 318:

form_class = forms.TypedChoiceField

In my case, I have a subclass of TypedChoiceField which I would like to use to display the field. Instead of the simple bit of code shown above, however, I had to duplicate the entire formfield function from the base Field class, and change that one offending line.

[Malcolm Tredinnick]

Changed description to match the problem.

[Badri]

Replying to badri:
I have uploaded the patch twice. please delete the first one.

[Malcolm Tredinnick]

Seems to have been accidentally marked as "fixed". Reopening.

[Skaffen]

Just a quick note: I've hit this issue for a different reason.

In my circumstance I'm passing in "choices" to a ManyToManyField declaration (as I don't want to use a query to declare the choices) which is leading to the model form setting the corresponding field up as a TypedChoiceField. This, of course, has a single selection widget as its default widget rather than multiple select.

[Julien Phalip]

The tests would need to be rewritten using unittests since this is now Django's preferred way.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Łukasz Langa]

I ended up creating a new patch since the old one used doctests and the solution was based on a hardcoded list of form fields that should be overriden which basically reintroduced the same problem in a different form.

[Łukasz Langa]

Patch for 1.4RC

[Łukasz Langa]

An alternative patch which puts the responsibility of handling overrides on model fields

[Julien Phalip]

Thank you for your work and sorry for the late review.

In the revised patch attached, I've moved the logic to a new, separate method called choices_formfield(). This complicates the API slightly, but at least it removes the necessity for all subclasses of Field to modify their logic based on self.choices.

I'll seek some feedback. If this approach is approved then some documentation will be needed.

[David Gouldin]

Julien, this patch will not work as-is. Your new Field.choices_formfield function is called from Field.formfield using **defaults, but defaults will never include form_class. This means that Field.choices_formfield will always be called with its default value for form_class (None unless overridden by a custom Field subclass) even when the user's intent was to provide a custom form_class for that model field. So for this model:

class Foo(models.Model):
    bar = models.IntegerField(choices=bar_choices, form_class=MyCustomFormClass)

MyCustomFormClass would never make it to bar's Field.choices_formfield, and so an instance of it would not be returned by Field.formfield.

However, it also not work to simply call self.choices_formfield(form_class=form_class, **defaults) from Field.formfield. Subclasses of Field (such as IntegerField) frequently override formfield() and call super's formfield() with a form_class kwarg. This means that calling Field.choices_formfield with Field.formfield's form_class would break models like this:

class Foo(models.Model):
    bar = models.IntegerField(choices=bar_choices)

In this case, IntegerField.formfield would call Field.formfield with form_class=forms.IntegerField, which would then be passed through to Field.choices_formfield, causing forms.TypedChoiceField not to be used as was intended.

As the implementation sits currently, Field has no way to determine whether the intent of the user was to specify their own form_class or whether the Field subclass injected its own form_class before calling Field.formfield. This is broken, plain and simple. In order for Field.formfield to make a good decision about which class to use when instantiating a form field, it needs both pieces of information: the model field's default form_class, and the user's override of that default (if provided). Here's the solution I propose:

class Field(object):
    default_form_class = forms.CharField

    # ...

    def formfield(self, form_class=None, **kwargs):
        if self.choices:
            form_class = form_class or forms.TypedChoiceField
            # ...
        else:
            form_class = form_class or self.default_form_class


class IntegerField(Field):
    default_form_class = forms.IntegerField

This allows Field.formfield to have both pieces of information, and it alleviates the need for IntegerField to override formfield. It is not backwards compatible, as any model field subclasses which use this formfield override approach would need to be changed to fit the new default_form_class property approach.

[Claude Paroz]

Seems this issue has been fixed (#18162, [b6f4a92ff45d98a63dc29402d8ad86b88e6a6697]).