Inline Editing Related Models

From Separate Forms to an Integrated View

Imagine you have a Project model and a Task model, where each Task belongs to a Project. Without inlines, your workflow would be:

1. Go to the Project admin and create a new project.
2. Go to the Task admin.
3. Create a new task, and use a dropdown to select the project you just created.
4. Repeat for every single task.

This is inefficient and disconnected. Inline editing allows you to add, edit, and delete tasks directly on the Project edit page, providing a much more intuitive and cohesive interface. Since you have experience with SQL, you can think of this as bringing the "many" side of a one-to-many relationship directly into the admin page for the "one" side.

Implementing Inline Model Admins

To achieve this, Django provides two main classes that you can inherit from:

• admin.StackedInline: Displays each related object as a full block of fields, similar to a standard admin form.
• admin.TabularInline: Displays each related object in a more compact, table-based row.

Let's start by looking at a clear example from the MDN Django tutorial.

The process you just read about can be summarized as:

1. Create a class that inherits from admin.TabularInline or admin.StackedInline.
2. Set the model attribute of this class to your "child" model (the one with the ForeignKey).
3. In your "parent" ModelAdmin class, add an inlines attribute, which should be a list containing your newly created inline class.

The result of using TabularInline is a clean, row-based layout for related objects, as shown in the image below.

Choosing Between TabularInline and StackedInline

The choice between TabularInline and StackedInline is mostly about presentation.

• TabularInline is best when the related model has just a few fields. It's compact and easy to scan.
• StackedInline is better when the related model has many fields, as it gives each field its own line and more space, preventing the form from becoming too wide and hard to read.

The following video demonstrates this difference clearly and also introduces a useful customization option.

As you saw, setting extra = 0 is a common practice. It creates a cleaner interface by hiding the empty forms until you explicitly click "Add another...".

A Crucial Rule: The Direction of the ForeignKey

There is one critical rule you must follow for inlines to work: The model being inlined must have a ForeignKey to the parent model.

You cannot, for example, inline the User model on a Recipe admin page if the Recipe model has a ForeignKey to User. The relationship is in the wrong direction. The Recipe is the "child" that points to the User "parent". Therefore, you can inline recipes on the user's admin page, but not the other way around.

This concept can be tricky, and seeing the error it produces is the best way to understand it. The next segment of the video does an excellent job of demonstrating this.

This is a fundamental concept. The inlines list effectively tells Django: "On this parent admin page, show me all the children that point to this specific parent instance."

# projects/models.py
from django.db import models
from django.conf import settings

class Project(models.Model):
    name = models.CharField(max_length=200)
    owner = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.CASCADE)
    start_date = models.DateField()

    def __str__(self):
        return self.name

class Task(models.Model):
    project = models.ForeignKey(Project, on_delete=models.CASCADE, related_name='tasks')
    description = models.CharField(max_length=255)
    is_completed = models.BooleanField(default=False)

    def __str__(self):
        return self.description

from django.contrib import admin
from .models import Project, Task

class TaskInline(admin.TabularInline):
    model = Task
    extra = 0 # Don't show any extra forms by default

@admin.register(Project)
class ProjectAdmin(admin.ModelAdmin):
    list_display = ('name', 'owner', 'start_date')
    inlines = [TaskInline]

# We can also register the Task model on its own if we want a separate admin for it
admin.site.register(Task)

Conclusion

You have now completed the final core competency for customizing the Django admin. By combining list_display, search_fields, list_filter, fieldsets, and now inlines, you can build a highly efficient and user-friendly data management interface for almost any application.

Key Takeaways:

• Inline editing allows you to manage related objects (the "many" side of a relationship) directly on the parent object's admin page.
• Use admin.TabularInline for a compact, table-like layout, and admin.StackedInline for a more spacious, form-like layout.
• The model you want to inline must have a ForeignKey pointing to the parent model.
• Configuration involves creating an inline class (specifying its model) and adding it to the parent ModelAdmin's inlines list.
• The extra attribute in an inline class controls how many empty forms are shown for adding new related objects. Setting extra = 0 is common.

This lesson concludes our module on the Django Admin. You are now well-equipped to build powerful internal dashboards. In our next module, we will shift our focus back to the user-facing part of your application. We'll begin by exploring Class-Based Views (CBVs), a powerful, reusable, and object-oriented way to handle web requests that builds on the function-based views you've seen before.