General questions#

This page answers high-level questions about the project, its scope, and its lifecycle.

What is next.dj and is it a Django replacement #

next.dj is a framework built on Django, not a replacement for it. It adds file-based routing, a layout system, reusable components, form dispatch, and partial rendering on top of a regular Django project. See Overview, especially What next.dj does not replace, for what stays stock Django versus what the framework adds.

Which Django and Python versions are supported #

The Installation Requirements list names the tested Python and Django combinations.

Is next.dj production ready #

Run manage.py check to confirm a deployment matches framework expectations, and pin a supported Python and Django release (see Installation). See Which symbols are safe to depend on below for guidance on the public API surface.

How do I follow the project #

Watch the repository on GitHub. Releases ship through PyPI under the distribution name next.dj, imported as next (see Installation). Discussions and feature requests live on GitHub Discussions.

How is this different from plain Django forms #

A next.dj form needs no URL entry and no view. Subclassing next.forms.Form or next.forms.ModelForm registers it and attaches a POST endpoint, CSRF, and a re-render-on-failure pipeline (see Forms overview). A failed submission re-renders the origin page with the entered values and field errors instead of an error page, so you write no re-render code (see Validation and re-render). A next.forms.FormWizard persists per-step data through a configured backend rather than hand-managed session keys (see Form wizards).

When to use FormWizard versus rolling your own session logic #

Use next.forms.FormWizard when a flow spans several steps that share a final commit, where you would otherwise stash partial data in the session and wire step routing, back-navigation, and conditional branching by hand. A single form, or two independent forms with no shared finalisation, does not need a wizard.

What about plugins #

The project does not ship a plugin registry. The five extension mechanisms in Extending cover the common cases. Distribute your customisations as ordinary Python packages.

What about a CLI #

The framework does not add a new CLI. Django’s manage.py plus the framework system checks cover the operational surface.

Which symbols are safe to depend on #

Two rules define the public surface. First, anything exported from a top-level next.* package is safe to import. Second, symbols whose names start with a single underscore are internal and may change without notice, even when they appear in a module __all__. The underscore rule is binding and overrides any incidental re-export. See Forms reference for a concrete example of how the API tiers apply to next.forms.