On 12/9/07, James Bennett <[EMAIL PROTECTED]> wrote: > > OK, so after chatting a bit with Joseph on IRC I'm working on revising > my original patch. The changes it makes still need some discussion, so > I'll outline them here. > > 1. The "instance" argument to ModelForm.__init__() essentially becomes > a keyword argument defaulting to None, and moves out of the first > position in the argument list. > 2. If "instance" is None, the model to generate a form for will be > determined by the "model" attribute of the ModelForm's inner Meta > class. > 3. Defining a ModelForm subclass without specifying "model" in the > inner Meta class, and without passing "instance" when instantiating > the form, is an error and raises ImproperlyConfigured (same as other > errors, such as a ModelForm which tries to define itself for multiple > models at once). > > This would mean that the snippet of code in my original reply to > Joseph would actually work, and that a ModelForm could be defined > without being bound to any particular model, still accept the "fields" > and "exclude" options, and then determine the model to work with at > instantiation time. That feels kind of neat to me, but is probably > worth debating.
I'm close to checking this in and adding a note to BackwardsIncompatibleChanges, but I'm still a little uneasy about generating the form fields at form instantiation time. It just feels weird to me, but I can't really come up with any actual reasons why. I mean, I think the functionality is neat, but I'm not comfortable with the syntax. Anyone have opinions or reasoning one way or the other? Joseph --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
