Opened 15 years ago

Last modified 2 weeks ago

#10403 assigned New feature

provide declarative syntax to define FormSets - including ModelFormSet and InlineFormSet

Reported by: Koen Biermans <koen.biermans@…> Owned by: Mitchina
Component: Forms Version: dev
Severity: Normal Keywords: formset modelformset inlineformset
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Provide a declarative mechanism to define modelformsets or inlineformsets.

The attached patch allows definitions like this:

class AuthorForm(forms.ModelForm):
    class Meta:
        model = Author

class DeclarativeAuthorFormSet(forms.models.ModelFormSet):
    form = AuthorForm
    model = Author
    extra = 3

and

class BookForm(forms.ModelForm):
    class Meta:
        model = Book

class DeclarativeAuthorBooksFormSet(forms.models.InlineFormSet):
    model = Book
    form = BookForm
    parent = 'author'

An advantage is that the defined form is directly used as the form class in the formset, not as a base class for a new form class (what inlineformset_factory does). This way specific field definitions and other customisations in the form work like they should so you don't need to redefine things in init().

Attachments (2)

declarativeformsets.diff (15.9 KB ) - added by Koen Biermans <koen.biermans@…> 15 years ago.
patch to provide declarative syntax for modelformset and inlineformset
django-10403.diff (27.7 KB ) - added by Bas Peschier 13 years ago.

Download all attachments as: .zip

Change History (15)

by Koen Biermans <koen.biermans@…>, 15 years ago

Attachment: declarativeformsets.diff added

patch to provide declarative syntax for modelformset and inlineformset

comment:1 by Jacob, 15 years ago

Triage Stage: UnreviewedDesign decision needed

comment:2 by Chris Beaven, 13 years ago

Severity: Normal
Type: New feature

comment:3 by Stephen Burrows, 13 years ago

Easy pickings: unset
Keywords: formset added
Needs documentation: set
Needs tests: set
Patch needs improvement: set
Summary: provide declarative syntax to define ModelFormSet and InlineFormSetprovide declarative syntax to define FormSets - including ModelFormSet and InlineFormSet
UI/UX: unset

Closed #16289 as a duplicate - it proposed essentially the same thing as this ticket, but included all FormSets, not just ModelFormSets. Hence I'm widening the scope of this a little. (Also marking as needs tests since the tests in the patch are doctests.)

comment:4 by Bas Peschier, 13 years ago

Ok, so I missed this one O:)

I disagree with the implementation in the patch, no MetaClass is needed and just simple additions to the class definitions to make it work, maybe with the exception of InlineFormSet. Will attach a patch later on.

by Bas Peschier, 13 years ago

Attachment: django-10403.diff added

comment:5 by rasca, 12 years ago

Adding a comment from #16289:

This would be very useful for a nicer implementation of the formset derived cbv #16256.

The BaseInlineFormSet? is the only tricky one with the _get_foreign_key() and the max_num override when fk.unique=True .

I'd also move the defaults (e.g. extra=3) to the BaseFormSet? and make the factories only pass dict keys whose value isn't None to type().

comment:6 by Carl Meyer, 11 years ago

Triage Stage: Design decision neededAccepted

The current factory-function implementation of formsets is unnecessarily confusing to new users, and unlike anything else in Django. It can also cause obscure issues with things that should "just work" (see e.g. http://stackoverflow.com/questions/622982/django-passing-custom-form-parameters-to-formset/624013#624013). It's ironic that we provide declarative syntax for things like models and forms where it requires metaclass magic, but in the case of formsets where a declarative syntax is a simple matter of normal Python subclassing, we don't :-)

Haven't reviewed the latest patch in depth, but the broad strokes look correct to me.

comment:10 by Tim Graham, 8 years ago

I don't know that deprecating the factory functions (at least immediately) is a good idea. This could cause a lot of annoying churn for large projects.

comment:11 by Parth Patil, 5 years ago

Owner: changed from nobody to Parth Patil
Status: newassigned

comment:12 by Parth Patil, 5 years ago

Here is a link to the pull request. This is the first iteration of the patch so may require some critical review.
https://github.com/django/django/pull/11481

comment:13 by Asif Saifuddin Auvi, 4 years ago

Parth, are you willing to complete this for 3.1?

comment:14 by Mitchina, 8 weeks ago

Owner: changed from Parth Patil to Mitchina

comment:15 by Mitchina, 3 weeks ago

I opened a PR (still in draft) to continue the work initiated by Parth Patil on: https://github.com/django/django/pull/17905

comment:16 by Mitchina, 2 weeks ago

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Note: See TracTickets for help on using tickets.
Back to Top