Build Dynamic Django Forms from Data: Render Inputs from DataFrame Columns or QuerySet Values

Learn how to build dynamic Django forms by rendering inputs from DataFrame columns or QuerySet values. Loop over field names in the template—no Form classes.

Building forms dynamically from data is a common need: you have a DataFrame or a QuerySet, and you want the form fields to be rendered based on the column names rather than being hardcoded. In other words, the structure of the form should be the outcome of data processing, not something declared upfront in a class.

The static approach that blocks you

Here’s a minimal example of a traditional, static form where field names are fixed in code. It illustrates why this pattern can’t adapt to runtime data.

from django import forms
# a static form wired at import time
class StaticForm(forms.Form):
    given_name = forms.CharField(max_length=200)
    family_name = forms.CharField(max_length=200)
    reg_no = forms.IntegerField(help_text="Enter 6 digit roll number")
    secret = forms.CharField(widget=forms.PasswordInput())
from django.shortcuts import render
from .forms import StaticForm
# view that passes a pre-defined form instance
def index(request):
    payload = {}
    payload['form'] = StaticForm()
    return render(request, "home.html", payload)
# home.html template
<form action="" method="post">
    {% csrf_token %}
    <table>
        {{ form.as_table }}
    </table>
    <input type="submit" value="Submit">
</form>

What actually goes wrong

When fields are declared in a Django Form class, their names and widgets are defined once and stay unchanged. That’s perfect for stable schemas, but it doesn’t work when the required inputs should be inferred from data, such as a DataFrame’s columns or a QuerySet’s keys. The form ends up being a rigid contract, but the goal here is to derive the contract from the data itself.

A lean pattern: render inputs from data

Instead of defining a Form, pass a list of field names to the template and render simple inputs in a loop. This keeps the structure driven by the dataset.

# view: provide the field names that should become inputs
def index(request):
    context = {}
    context['field_names'] = ['column1', 'column2', ...]
    return render(request, "home.html", context)
# home.html: loop over names to produce labels and inputs
<form>
{% csrf_token %}
{% for name in field_names %}
  <label for="{{ name }}">{{ name }}</label>
  <input type="text" name="{{ name }}">
{% endfor %}
</form>

This approach meets the requirement directly: the template doesn’t know the fields ahead of time; it simply renders whatever list the view provides.

Getting the field names from a QuerySet or a DataFrame

To feed the template, derive the names from your data source and place them in the same list.

# from a QuerySet: take keys from a dict in .values()
context['field_names'] = list(your_model.objects.all().values()[0])

# from a DataFrame: take the column labels
context['field_names'] = list(your_dataframe.columns.values)

Why this approach matters

When the schema is data-driven, enforcing a static form definition is counterproductive. Rendering inputs directly from a list lets the UI reflect the current dataset without extra plumbing. It also keeps the view responsible for shaping the schema, while the template focuses on display. That separation is practical when you want a straightforward way to map column names to editable fields.

Practical wrap‑up

If you need a form whose fields are defined by the content of a DataFrame or a QuerySet, avoid static Form classes. Assemble a list of field names in the view and render inputs in the template via a simple loop. Pull the names from a QuerySet with values()[0] or from a DataFrame via columns.values, and pass them as context. This gives you a compact, flexible pattern that keeps the form structure aligned with your data.