Digging into the documentation it turns out that for [ModelForm initial
overrides instance values
https://docs.djangoproject.com/en/2.2/topics/forms/modelforms/#providing-
initial-values] ("Initial values provided this way will override both
initial values from the form field and values from an attached model
instance.") whereas for [normal Forms initial
https://docs.djangoproject.com/en/2.2/ref/forms/api/#dynamic-initial-
values] does not take precedence over bound data ("These values are only
displayed for unbound forms, and they’re not used as fallback values if a
particular value isn’t provided."). Maybe that's my mistake for thinking a
bound Form and a ModelForm with an instance are roughly equivalent.
I tracked this down to [this commit
https://github.com/django/django/commit/51dc4ecf943d1dcc044ed956925760f9d480f56c]
12 years ago and it seems that nobody has complained much about this piece
of code in the mean time. So maybe it isn't a problem but I think there is
something to be said for reversing the precedence in ModelForm.
I've attached a draft diff to fix this.
--
Ticket URL: <https://code.djangoproject.com/ticket/30407>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* Attachment "modelform_reverse_initial.diff" added.
draft patch
Old description:
> We ran into a bug (on our side) where our data was not being displayed in
> a ModelForm for existing instance because we were setting both initial
> values as the instance in the ModelForm.
>
> Digging into the documentation it turns out that for [ModelForm initial
> overrides instance values
> https://docs.djangoproject.com/en/2.2/topics/forms/modelforms/#providing-
> initial-values] ("Initial values provided this way will override both
> initial values from the form field and values from an attached model
> instance.") whereas for [normal Forms initial
> https://docs.djangoproject.com/en/2.2/ref/forms/api/#dynamic-initial-
> values] does not take precedence over bound data ("These values are only
> displayed for unbound forms, and they’re not used as fallback values if a
> particular value isn’t provided."). Maybe that's my mistake for thinking
> a bound Form and a ModelForm with an instance are roughly equivalent.
>
> I tracked this down to [this commit
> https://github.com/django/django/commit/51dc4ecf943d1dcc044ed956925760f9d480f56c]
> 12 years ago and it seems that nobody has complained much about this
> piece of code in the mean time. So maybe it isn't a problem but I think
> there is something to be said for reversing the precedence in ModelForm.
>
> I've attached a draft diff to fix this.
New description:
We ran into a bug (on our side) where our data was not being displayed in
a ModelForm for existing instance because we were setting both initial
values as the instance in the ModelForm.
Digging into the documentation it turns out that for [ModelForm
https://docs.djangoproject.com/en/2.2/topics/forms/modelforms/#providing-
initial-values] initial overrides instance values ("Initial values
provided this way will override both initial values from the form field
and values from an attached model instance.") whereas for normal [Forms
https://docs.djangoproject.com/en/2.2/ref/forms/api/#dynamic-initial-
values] initial does not take precedence over bound data ("These values
are only displayed for unbound forms, and they’re not used as fallback
values if a particular value isn’t provided."). Maybe that's my mistake
for thinking a bound Form and a ModelForm with an instance are roughly
equivalent.
I tracked this down to [this commit
https://github.com/django/django/commit/51dc4ecf943d1dcc044ed956925760f9d480f56c]
12 years ago and it seems that nobody has complained much about this piece
of code in the mean time. So maybe it isn't a problem but I think there is
something to be said for reversing the precedence in ModelForm.
I've attached a draft diff to fix this.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30407#comment:1>
* status: new => closed
* resolution: => wontfix
* version: 2.2 => master
* type: Bug => New feature
Comment:
This behavior is documented and expected (as you mentioned above), so a
change will be backward incompatible. You can start a discussion with your
proposal on
[https://groups.google.com/forum/?utm_source=digest&utm_medium=email#!forum
/django-developers/topics django-developers] if you think that this should
be changed.
--
Ticket URL: <https://code.djangoproject.com/ticket/30407#comment:2>
Comment (by Alper Cugun):
OK. I think I expected as much. Thanks for clearing this up and at least
now it's documented here as well.
--
Ticket URL: <https://code.djangoproject.com/ticket/30407#comment:3>