I'm not seeing this, I've modified Django model_forms modeltest to
exercise what I interpret from your report and the new test passes
and shows identical behavior with both 1.1beta (r10133) and 1.1:
Please modify these tests to describe what you are seeing if I've
missed anything.
Regards,
PS: Maybe you are not seein the difference in behavior at model
instance save time as per what's described in the docs in the note
right above this?:
http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#overriding-the-default-field-types
--
Ramiro Morales
http://rmorales.net
PyCon 2009 Argentina - Vie 4 y Sab 5 Setiembre
Buenos Aires, Argentina
http://ar.pycon.org/2009/about/
Hi David,
Thanks for this report. I'll have to dig a bit deeper to see exactly
what is going on here. If you want to help out, working out which
changeset between 10132 (beta 1) and 11365 (1.1 final) introduced this
discrepancy would be extremely helpful.
I'd also be interested to hear which behaviour - history and personal
uses notwithstanding - you think is correct. On first inspection, I'm
not completely convinced that the 'new' behaviour is actually
incorrect - or, at least, that there might be a larger bug lurking
here with regard to the interpretation of inherited Meta.field
arguments. However, this is entirely based on first impressions, late
at night, with a mild headache, so I could be completely off base.
Yours
Russ Magee %-)
Thanks for taking the time to do the analysis and explanation. I've
now had a closer look at this - unfortunately, I'm inclined to say the
exact opposite. I think ModelForm is doing the right thing.
My reasoning stems from the fact that we are dealing with a ModelForm,
not just a Form, and the 'Meta' definition is the highest source of
authority.
DataParentForm defines a Meta relationship with the DataParent model,
and explicitly defines that only the 'name' field is to be exposed.
DataChildForm inherits from DataParentForm, and while it overrides the
model relationship, it doesn't override the fields definition - so at
this point, we have a ModelForm on DataChild that only exposes the
'name' field.
Then, you have added a 'value' field to the model. While this does
share the name of a field on the model, this is a coincidence - you
have explicitly stated that you don't want the 'value' field from the
model to be involved on the form. The 'value' FloatField could be
called anything else without error - by virtue of the inherited Meta
definition, it bears no relationship to the underlying model.
If, on DataChildForm, you add a fields definition:
fields = ['name','value']
the explicitly defined FloatField becomes an override of the default
form element rather than a standalone form element, and as a result
the initial data is populated.
The behaviour for ModelFormSet is then consistent with that seen in
the ModelForm.
So - to my mind, the v1.1 behaviour of ModelForm is doing the right
thing. I agree that this is a nasty edge case though, and I'd be
interested to hear if anyone has any differing opinions or reasoning.
Yours,
Russ Magee %-)
For what it's worth, I agree with Russell's analysis here. If you're
inheriting from a parent class, you are saying your subclass "is-a"
instance of the parent and you can't put back things from the model the
parent has already excluded. That isn't "is-a", it's
"same-but-different".
Regards,
Malcolm
Absolutely. We aren't striving for ambiguity, so any suggestions on
how we can clarify the docs in this regard are most welcome. Please
open a ticket for the general suggestion (perhaps with a summary of
the problem so we know what it is we're trying to explain); if you
have some draft text, drop it in a patch or a comment.
Yours,
Russ Magee %-)