On Mon, Aug 3, 2009 at 3:46 AM, David Haas<david.h.h...@gmail.com> wrote:
>
> It looks like the change happened between rev. 10189 & 10190: 10189
> displays the value, 10190 doesn't.
>
> Unfortunately, I don't think I can give you a completely unbiased
> answer as to what behavior I think
> is more correct, because of history and personal use :)
>
> With that out on the table, though, it seems to me that if you are
> using a model form, and you're initializing
> it with a model instance, and that model instance has a current value
> for a field on your form, the form
> ought to get initialized with that value, regardless of whether or not
> you plan on eventually saving the
> field in the database or not. If you're going to display it, it ought
> to reflect what's currently in the database.
> I think I've read some stuff about eventually making 'read only'
> forms, or marking fields on a form as 'read only', which seems like it
> could tie into this somehow, eventually, maybe.
>
> If you agree with that, though, then currently both ModelForms &
> ModelFormsets initialization is broken, because
> neither fills in the values.
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 %-)
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
