What about replacing the idea of a ModelForm with a ModelField? Then for shorter forms you could list all the fields explicitly, without having to recode all the default field definitions.
e.g.: class MyForm(forms.Form): foo = forms.ModelField(SomeModel, 'foo', widget=forms.Textarea) bar = forms.ModelField(AnotherModel, 'bar') baz = forms.CharField(max_length=100) class Meta: fields = ( (YetAnotherModel, '*') # field names will be 'yet_another_model_field1', etc. ) exclude = ( (YetAnotherModel, 'internal_field') ) # init_field_<field> is called for each field when the form is instantiated def init_field_yet_another_model_field1(self, field): field.widget = forms.Textarea return field ~David On Apr 2, 5:55 pm, "James Bennett" <[EMAIL PROTECTED]> wrote: > On Wed, Apr 2, 2008 at 7:06 PM, msaelices <[EMAIL PROTECTED]> wrote: > > Now, what do you see? You first think again in a form with two fields, > > however maybe is a form with five fields. What is happening? You > > explicity define two fields, and the real action is a _redefinition_ > > of two fields. > > > Django philosophy talk about "Explicit better than implicit", but in > > this point ModelForms is not very intuitive. > > Obligatory counterpoint: it's not "intuitive", but that's an awfully > loaded word, since no two programmers ever born will agree on what is > and isn't "intuitive". And I'm not sure "intuitive" is even a good > thing to aim for, because... > > A better counterpoint would be to consider this class: > > class MyForm(forms.Form): > name = forms.CharField(max_length=25) > favorite_color = forms.CharField(max_length=10) > > A simple form with two fields, right? > > OK, how about this: > > class MyOtherForm(MyForm): > favorite_food = forms.CharField(max_length=20) > > By the same argument, this is "unintuitive" because you have to notice > that it's subclassing another form and adding a field, so that it has > three fields instead of just the one that's explicitly defined. And, > in fact, this sort of thing is not uncommon at all in Python; any time > you see something being subclassed, it's a sign you should find out > what the parent class does, because the subclass definition may not > tell the whole story. > > In the case of a ModelForm, it's even a bit easier because you know -- > from the inner 'Meta' class -- what model it's going to draw its base > field definitions from. > > So I'm not convinced that there's any problem here that needs fixing; > you can't just skim over a piece of code without paying attention to > what it's doing (rather than being "intuitive", I like to call that > "dangerous"), so you see that it's subclassing ModelForm and either go > look up what that means (if you don't know what the ModelForm class > does) or look up the model it draws its fields from (if you do), and > there are no surprises. > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---