🧭 Function-Based Views

What Is a View?

In Django's MVT (Model–View–Template) architecture, a view is the code that decides what should happen when a particular URL is requested. It receives an HttpRequest object, does whatever work the page needs — query a model, validate a form, check permissions — and returns an HttpResponse (or raises an exception that Django turns into one).

💡 A useful analogy: A view is like a restaurant server. It takes the customer's order (the request), relays it to the kitchen and pantry (the models), arranges the result on a plate (the template), and carries it back to the table (the response). The server doesn't cook or store the food — it coordinates.

Every view is just a callable that maps a request to a response. Django supports two flavours: function-based views (a plain function, the focus of this lesson) and class-based views (covered next). FBVs are the clearest starting point because everything the view does is visible in one place — there is no inherited behaviour hiding off-screen.

Anatomy of a Function-Based View

The smallest possible view takes the request and returns a response:

from django.http import HttpResponse

def hello_world(request):
    return HttpResponse("Hello, World!")

Three things are always true of a function-based view:

• Its first positional argument is the request — an HttpRequest instance carrying the method, headers, query string, POST data, the logged-in user, and more.
• It returns an HttpResponse (or a subclass like JsonResponse / HttpResponseRedirect), or raises an exception such as Http404.
• Any extra arguments come from captured URL parameters (you'll see these shortly).

Returning raw strings is rare in practice. Real views nearly always render a template or return structured data, which is where the render() shortcut comes in.

Rendering Templates & Model Data

The render() shortcut combines a request, a template name, and a context dictionary into a fully rendered HttpResponse:

from django.shortcuts import render

def homepage(request):
    context = {
        "title": "Welcome to My Site",
        "message": "This is the homepage.",
    }
    return render(request, "blog/homepage.html", context)

The template can then reference {{ title }} and {{ message }}. Most views, though, pull their data from the database first. Because a Django QuerySet is lazy, the query below doesn't hit the database until the template actually iterates over posts:

from django.shortcuts import render
from .models import Post

def post_list(request):
    posts = Post.objects.filter(status="published").order_by("-published_date")
    return render(request, "blog/post_list.html", {"posts": posts})

URL Parameters & Wiring

A view is useless until a URL points at it. In modern Django you use path() with path converters that both match and type-convert part of the URL, passing it to the view as a keyword argument:

# blog/urls.py
from django.urls import path
from . import views

app_name = "blog"

urlpatterns = [
    path("", views.post_list, name="post_list"),
    path("post/<int:post_id>/", views.post_detail, name="post_detail"),
    path("category/<slug:slug>/", views.category_posts, name="category_posts"),
]

The captured value arrives as an argument of the same name. Use get_object_or_404() so a missing row produces a clean 404 instead of a 500 error:

from django.shortcuts import render, get_object_or_404
from .models import Post

def post_detail(request, post_id):
    post = get_object_or_404(Post, id=post_id, status="published")
    return render(request, "blog/post_detail.html", {"post": post})

Handling Forms: GET and POST

A single view usually handles both showing an empty form (a GET request) and processing a submitted one (a POST request). The idiomatic shape checks request.method and follows the Post/Redirect/Get pattern — after a successful POST you redirect so a page refresh can't resubmit the form:

from django.shortcuts import render, redirect
from django.contrib import messages
from .forms import ContactForm

def contact(request):
    if request.method == "POST":
        form = ContactForm(request.POST)
        if form.is_valid():
            # form.cleaned_data holds validated, typed values
            form.send_email()
            messages.success(request, "Thanks — your message was sent.")
            return redirect("blog:contact_success")   # PRG: redirect on success
    else:
        form = ContactForm()   # unbound, empty form for GET

    return render(request, "blog/contact.html", {"form": form})

When the form is invalid, execution falls through to the final render() — but now form is bound and carries error messages, so the template can display them next to the offending fields. Always include {% csrf_token %} inside the <form> in your template; Django rejects unprotected POSTs.

Decorators & JSON Responses

Decorators wrap a view to add reusable behaviour without cluttering its body. A few you'll reach for constantly:

from django.contrib.auth.decorators import login_required, permission_required
from django.views.decorators.http import require_http_methods, require_POST

@login_required
def dashboard(request):
    return render(request, "blog/dashboard.html")

@permission_required("blog.add_post", raise_exception=True)
def create_post(request):
    ...

@require_http_methods(["GET", "POST"])
def edit_profile(request):
    ...

For an API-style endpoint, return JsonResponse instead of HTML. The @require_POST decorator guarantees the view only runs for POST requests:

from django.http import JsonResponse
from django.contrib.auth.decorators import login_required
from django.views.decorators.http import require_POST
from django.shortcuts import get_object_or_404
from .models import Post, Like

@login_required
@require_POST
def toggle_like(request, post_id):
    post = get_object_or_404(Post, id=post_id)
    like, created = Like.objects.get_or_create(user=request.user, post=post)
    if not created:
        like.delete()
    return JsonResponse({
        "liked": created,
        "like_count": post.likes.count(),
    })

Hands-on Exercise

from django.shortcuts import render, redirect, get_object_or_404
from .models import Post
from .forms import CommentForm

def post_detail(request, post_id):
    post = get_object_or_404(Post, id=post_id, status="published")
    comments = post.comments.filter(approved=True).select_related("author")

    if request.method == "POST":
        if not request.user.is_authenticated:
            return redirect("login")
        form = CommentForm(request.POST)
        if form.is_valid():
            comment = form.save(commit=False)
            comment.post = post
            comment.author = request.user
            comment.save()
            return redirect("blog:post_detail", post_id=post.id)
    else:
        form = CommentForm()

    return render(request, "blog/post_detail.html", {
        "post": post,
        "comments": comments,
        "form": form,
    })

Best Practices

When FBVs shine: highly custom, one-off logic — a webhook receiver, a dashboard that aggregates several sources, a bespoke multi-form page. When a view is really just "list these objects" or "edit this object," the class-based generics in the next lesson do it in a fraction of the code.

Summary & Quiz

📚 Further Reading

• Django Docs — Writing views
• Django Docs — render, redirect & get_object_or_404
• Django Docs — View decorators

🚀 What's Next?

Now that you can hand-write the whole request/response cycle, the next lesson introduces Class-Based Views — Django's object-oriented alternative that captures common patterns like "list objects" and "edit an object" so you can build the same features with far less code.