On 11/11/07, Russell Keith-Magee <[EMAIL PROTECTED]> wrote:
>
> The problem I have with ModelForm is that it doesn't feel like it has
> any parallels with the existing class-based formdefinitions. Manual
> Form definitions have a very similar flavour to Model definitions -
> each class attribute is a part of the model/form, etc. On one level,
> ModelForm tries to follow this lead by using a class-based syntax and
> allowing save() and clean() methods - but then it has a completely
> different approach to defining form fields, etc. In contrast,
> form_for_* doesn't looks anything like a manual form definition, so
> it's obvious that you're dealing with a different beast.
I see your point and I've been increasingly unhappy with my original
syntax for exactly those reasons, though you put it a lot more
eloquently than I would have. :) I came up with a new hybrid this
morning that I think addresses both of our concerns, and to me feels a
lot better than either of them.
class MyForm(ModelForm):
extra_field = SomeField()
class Options:
model = MyModel
fields = ['list', 'of', 'field', 'names']
def formfield_callback(db_field):
# return a formfield for the given db field
def save(self, commit=True):
# override save if you need to
def clean(self):
# override clean if you need to
This also allows for forms that have all their fields built by hand,
and not bound to any particular model class until instantiation:
class LatLongForm(ModelForm):
latitude = SomeCustomField()
longitude = SomeCustomField()
# Note there is no inner Options class and thus no model specified
# This form will work on any model instance with fields named
# 'latitude' and 'longitude'
def save(self, commit=True):
# override save if you need to
def clean(self):
# override clean if you need to
This way a Form still doesn't need its constructor changed, only the
ModelForm takes and object and has a save method.
To go along with this, I'd like to slightly change the signature of
the ModelForm constructor to this:
def __init__(self, obj, data=None, files=None...):
This would force people to instantiate and pass in an empty object for
add forms, and hopefully encourage a pattern of setting any defaults
on a model instance before you pass it to the form. I'm hoping this
will mean less people need to muck around with form.save(commit=False)
and the form.save_m2m() method.
> > The whole idea of a formfield callback is powerful, but it really
> > lacks in readability for the common tasks of specifying custom widgets
> > and excluding specific fields.
>
> Agreed. I would also add dynamically modifying the list of choices in
> a Select to this list of deficiencies.
I think during the last sprint we decided to add another custom method
type to forms to handle this. I thought there was a different ticket
that dealt with forms, but #3987 [1] is the closest I could find.
Maybe I'm just dreaming things up though.
[1] http://code.djangoproject.com/ticket/3987
Joseph
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
