formfield_callback is lost in an inherited ModelForm

[Ilya Semenov]

Consider the following code:

class BaseTicketForm(forms.ModelForm):
    class Meta:
        fields = (...)
    formfield_callback = lambda f: ....

class AddTicketForm(BaseTicketForm):
    pass

class EditTicketForm(BaseTicketForm):
    # some logic related to editing tickets here

When an instance of AddTicketForm or EditTicketForm is created, a user would expect that formfield_callback is applied. However, the current implementation doesn't do that; instead, a user is forced to copy-paste formfield_callback to each and every derived class.

[Ramiro Morales]

I'd say the fact that the value of formfield_callback is stored as a ModelForm class attribute is an internal implementation detail and that's why it isn't documented as such.

Anyway, maybe changing the pop() to get() here does it?: ​http://code.djangoproject.com/browser/django/trunk/django/forms/models.py?rev=12402#L204

[Ilya Semenov]

No, changing pop() to get() doesn't help. That does store a manually specified formfield_callback for a class; but that doesn't lookup a missing formfield_callback from a parent. Moreover, it will break on a double inheritance chain, e.g. when class A(ModelForm) stores a formfield_classback, class B(A) doesn't store but still can lookup parent, then class C(B) can't even lookup since B didn't store formfield_callback.

I am attaching a patch which adds the desired behavior accurately. Please let me know if it's of any interest to commiters and I will come up with a regression test.

[Ilya Semenov]

A little note for those who don't understand the importance of the problem. I truly believe that an empty inherited class should always behave exactly as its parent. That is a fundamental principle of polymorphism, which is not followed by ModelForms.

[Ilya Semenov]

a simplier version which leaves the inheritance/lookup logic to Python

[Russell Keith-Magee]

I'm not completely happy with either of the patches you present, but I accept the problem.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Stephen Burrows]

Also, just FTR - formfield_callback use *is* documented with modelform_factory.

[Ilya Semenov]

How'd you like to improve the latest patch? It's been 5 years, and I'm suffering from this again.

[Claude Paroz]

Writing a test would probably be the next step.

[Ilya Semenov]

Added tests: ​https://github.com/IlyaSemenov/django/tree/ticket_12915

I am not happy with the patch either, but the main problem here is the original design decision to provide formfield_callback as a class-level lambda rather than @staticmethod or a Meta class attribute.

Will it make it better if I come up with a patch which moves formfield_callback into the Meta class (where it would make perfect sense along with widgets and labels), or even allows to use either way (for backward compatibility)?

[Claude Paroz]

Replying to IlyaSemenov:

Will it make it better if I come up with a patch which moves formfield_callback into the Meta class (where it would make perfect sense along with widgets and labels), or even allows to use either way (for backward compatibility)?

Indeed, I think it would be an interesting alternative to consider.

[Tim Graham]

Duplicate of #24974 which is fixed in Django 1.10.