Fair enough. I've got some style questions about the best way to do what I want to do, but they're probably not so relevant here. Something that might be relevant is this . . . is it worth submitting a documentation patch for this issue? I was thinking something on this page:
http://docs.djangoproject.com/en/dev/topics/forms/modelforms/#using-a-subset-of-fields-on-the-form ... in the note box along the lines of "If you specify fields or exclude when creating a form with ModelForm, then the fields that are not in the resulting form will not be <new stuff>initialized by an model instance or </newstuff> set by the form's save() method. Thanks, - D On Aug 4, 11:28 pm, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Tue, 2009-08-04 at 22:23 +0800, Russell Keith-Magee wrote: > > On Mon, Aug 3, 2009 at 3:46 AM, DavidHaas<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 -~----------~----~----~----~------~----~------~--~---
