On Tue, 2009-08-04 at 22:23 +0800, Russell Keith-Magee wrote: > 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.
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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
