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
-~----------~----~----~----~------~----~------~--~---

Reply via email to