Inline formsets

[mrts]

At HTML level, a form is a set of fields that gets submitted when
a the form submit button is pressed.

However, this is not the case with model forms and inline formsets
(e.g. an admin page with inlines) -- inline formsets are
disparate from the model form.

This creates at least two problems:
1) it's impossible to display inline formsets in between ordinary
form fields (although they may logically belong to a particular
fieldset and not to the end of the form),
2) it's impossible to create nested (recursive) inlines.

There's more to it though. Inline formsets usually represent
composition, i.e. the inline objects are inseparable from the
main entity. The relation is stronger than a ForeignKey (from the
main entity to another entity), yet the latter is displayed as a
field of the form and can be easily manipulated -- but inlines
are not.

What I propose may at first sound odd: adding a *formset field*
to forms (keen readers notice the Composite pattern in work
here):

FormsetField(form=CustomFormClass, << other options inspired by
admin inlines and formset factories >>)

It would overcome both of the problems mentioned above and, being
object-based, would be generally more flexible than the factories
currently in use. Nested formsets can be trivially created:

class Foo(forms.Form):
foo = forms.FormsetField(...)

class Bar(forms.Form):
foos = forms.FormsetField(form=Foo, ...) # <-- nested formset

Rendering
---------

In an ideal world, the would-be formset field would support all
the niceness present or coming to Django admin: add/delete
instances on the fly, collapsing and reordering. That means
coupling JS to forms layer, which seems to be frowned upon.
Leaving either abstractions/hooks in place to support that
functionality and/or document how to bind the JS would
probably suffice though.

Implications for contrib.admin
------------------------------

FormsetField would be the recommended way for displaying and
manipulating inlines.

In yet another ideal world, assembling your own contrib.admin
would be trivial. All the functionality might be nicely packaged
to cohesive components (generic views, Alex's django-filter etc)
-- contrib.admin would be just a thin wrapper that binds all
reusable bits into a harmonious whole.

A rich FormsetField would contribute to that, making working with
formsets less onerous.

[Joshua Russo]

I think this sounds like a great idea. Do you have any code in place yet? This was probably the first thing I noticed I would like changed when getting into Django development. 

[Russell Keith-Magee]

On Sun, Aug 16, 2009 at 5:45 AM, mrts<mrts....@gmail.com> wrote:
>
> At HTML level, a form is a set of fields that gets submitted when
> a the form submit button is pressed.
>
> However, this is not the case with model forms and inline formsets
> (e.g. an admin page with inlines) -- inline formsets are
> disparate from the model form.
>
> This creates at least two problems:
> 1) it's impossible to display inline formsets in between ordinary
> form fields (although they may logically belong to a particular
> fieldset and not to the end of the form),

This is only true if you consider {{ form }} to be the only way to
render a form. Remember - you can modify your template to render
individual fields on a form. If you're looking for sophisticated
layout options, you should be looking at customizing your template,
not trying to turn Django's Form.as_ul into the One True Form
Rendering Tool (tm).

> 2) it's impossible to create nested (recursive) inlines.

This is true, but not necessarily a bad thing. I'm willing to be
convinced otherwise, but I'm yet to see a case where nested inlines
would yield a positive user experience. Forms inside forms inside
forms is a recipe for UI disaster.

Yours,
Russ Magee %-)