django-extra-views for Django formsets and inline editing

django-extra-views purpose and intended users

django-extra-views fills a specific gap in Django's built-in class-based generic views. Django supplies familiar views such as `FormView` and `ModelFormView`, while many applications also need to process several forms or edit a parent record together with related records. Repeating factory creation, formset assembly, and related-model handling in each view can make a Django application unnecessarily repetitive.

This package turns those recurring workflows into reusable Python classes. It is intended for developers building public or application-specific editing interfaces outside Django admin. Typical uses include a formset for several `AddressForm` instances, a `ModelFormSetView` for items sharing one model, and an order editor that changes the order, its items, and its contacts together.

It is a server-side Django extension rather than a complete interface layer. Developers still supply URLs, page design, forms, and application-specific validation. Its main benefit is concentrating repeated view construction into classes whose declarations resemble ordinary Django model and form configuration.

FormSetView and ModelFormSetView mechanisms

`FormSetView` accepts a form class and creates a formset through Django's `formset_factory`. The generated formset is placed in the view context, allowing a Django page to render and submit multiple related copies of the form. This works for forms that do not necessarily represent records from one model.

`ModelFormSetView` follows the same class-based pattern but uses Django's `modelformset_factory`. A developer names the model and its editable fields. That gives Django enough information to construct forms for the selected model records while the package handles the view-level formset workflow.

The separation makes sense when an application needs both types. A `FormSetView` is appropriate for a group of coordinated forms with custom validation or data that is not directly represented by one model. `ModelFormSetView` is closer to bulk editing a fixed model and is the starting point for related editing features. The README names these mechanisms but does not document all save-time hooks, deletion controls, or query customization options, so those details require checking the linked documentation or source.

CreateWithInlinesView and UpdateWithInlinesView

`InlineFormSetFactory` describes a related formset, while `CreateWithInlinesView` and `UpdateWithInlinesView` coordinate that formset with a parent model form. The repository example defines `ItemInline` and `ContactInline`, then includes both factories in an order view. This permits a single editing workflow to cover the order fields, its items, and its contacts.

The create and update classes accept similar declarations. Both use a model, a list of editable parent fields, and an `inlines` collection. `UpdateWithInlinesView` additionally operates on an existing model instance, but the README does not enumerate every internal difference between the two classes. Keeping separate names follows Django's conventional split between creation and update views while allowing the inline definitions to be reused.

Generic relations receive dedicated support through `GenericInlineFormSetView`, described as the counterpart to `InlineFormSetView` for `GenericForeignKeys`. The README also states that `CreateWithInlinesView` and `UpdateWithInlinesView` support generic inlines. This makes the package relevant to tag-like or otherwise polymorphic relationships, although the repository overview does not include a complete generic relation setup.

Installing django-extra-views and enabling extra_views

The README recommends installing the stable release from PyPI. The distribution is named `django-extra-views`, while application code imports modules from `extra_views`. After installation, Django must recognize the application through `INSTALLED_APPS`.

Use the documented installation command:

pip install django-extra-views

A successful installation places the package in the active Python environment. The project then needs this Django setting:

INSTALLED_APPS = [
    'extra_views',
]

The README also documents an editable installation from the GitHub master branch:

pip install -e git://github.com/AndrewIngram/django-extra-views.git#egg=django-extra-views

That second command follows repository code rather than the stable PyPI release. The package declares Python 3.6+ and Django 2.2-6.1 in the README, while `setup.py` declares Python 3.5 or later and Django 2.1 or later. This difference makes the actual dependency declarations and the target application environment worth checking before installation.

Building a first ModelFormSetView

A first implementation can follow the repository's item formset example. The view selects one model and the fields that users may change:

from extra_views import ModelFormSetView


class ItemFormSetView(ModelFormSetView):
    model = Item
    fields = ['name', 'sku']
    template_name = 'item_formset.html'

Connect `ItemFormSetView` through the project's Django URL configuration, then create `item_formset.html` with a POST form and a submission control. The formset is available through the `formset` context entry documented by the README. A GET request presents the formset, while a POST request is handled according to the package's formset view implementation.

No management command, data migration, or special database service is required by the documented setup. The underlying `Item` model still needs to exist before Django can construct its model forms. If item creation, deletion, ordering, or field visibility needs custom rules, those behaviors must be checked because the short README example does not define them.

Sorting, search, naming, and success messages

The package exposes several mixins for common list and submission behavior. `SortableListMixin` adds sorting functionality to a compatible view, while `SearchableListMixin` supplies search behavior. These components are separate from the formset classes, which means a project can adopt the relevant behavior without treating every extra view as one large abstraction.

`NamedFormsetsMixin` supports assigning names to each inline or formset in the Django context. That matters when a page contains several formsets and needs to distinguish them during rendering or submission. The feature addresses context naming; it does not replace formset validation or database behavior.

`SuccessMessageMixin` handles a success message after an ordinary form submission, and `FormSetSuccessMessageMixin` provides the formset-specific counterpart. The README does not show the attributes or methods used to configure either mixin, nor does it specify how messages behave on invalid submissions. Developers should consult the full documentation for the exact API instead of assuming configuration from a standard Django class.

Unfinished pagination and package boundaries

The most explicit limitation is pagination. The README lists support for pagination in `ModelFormSetView` and its derivatives as unfinished work. Its stated goal is to mimic Django admin's `change_list` view, but the author reports difficulty fitting the feature around `MultipleObjectMixin` pagination. A team that requires page-by-page editing should therefore verify the selected release rather than assume this functionality exists.

The repository's `setup.py` also classifies django-extra-views as `Development Status :: 3 - Alpha`. That label does not prevent use, but it is relevant when the package will support critical editing paths. The README does not document authorization rules, transaction behavior, rollback, or production deployment configuration. Those responsibilities remain with the Django project or must be established from the package's documented behavior.

The feature list is broader than the introductory examples. Sorting, searching, generic relations, named formsets, and success messages are named, but some configuration details are absent from the overview. This makes the linked documentation and source necessary during adoption, particularly for save hooks and validation across several formsets.

Django admin and custom view alternatives

Django admin is the closest built-in alternative when administrators need to edit model records and their inlines. It provides an established interface designed for exactly that kind of work. However, changing the interface, URL structure, or user workflow may require custom admin logic or a separate public-facing application view.

A custom Django function view is the other approach. It can implement only the factory creation and save behavior required by the project, but the application becomes responsible for repeated formset handling and parent-inline coordination. django-extra-views packages those pieces into reusable classes, which is valuable when several applications or views use the same editing pattern.

This is not a replacement for Django forms, models, URL routing, or page rendering. It adds reusable view composition around those existing tools. Choose Django admin when its management interface fits, choose a custom function view when unusual control is required, and choose django-extra-views when class-based application views can remove repeated formset and inline wiring.

django-extra-views maintenance, upgrades, and license

The repository is not archived, and its last push was on 2026-10-14. The listed releases are 0.7.1 on 2015-06-15, 0.7.0 on 2015-06-04, and 0.6.5 on 2014-08-11. This release history should be considered alongside the repository's alpha classification. Repository activity indicates a newer source state, but it does not establish that the published package includes every change.

The README directs readers to `tox.ini` for the supported Python and Django versions and names `tox` as the local test command:

tox

The contribution configuration adds `pre-commit`, `black`, `isort`, and `flake8` as repository checks. Upgrade planning should therefore include checking dependency compatibility and reviewing changes to formset save and validation behavior, especially where an application relies on several related formsets.

The project uses the MIT license. This identifies its declared licensing terms, while dependency licenses and required attribution remain separate considerations for an adopter.

Editorial conclusion

Adopt django-extra-views when a Django application needs class-based formsets or combined parent and inline editing without implementing that view machinery directly. Do not choose it for a paginated admin-style ModelFormSetView until that feature is available in the selected release. First verify the Python and Django versions, inspect the generated context, and test validation and save behavior for each related formset.

Frequently asked questions

Official sources

1. AndrewIngram/django-extra-views on GitHub
2. Issues
3. License: MIT
4. README
5. Releases