Core concepts

Key features

• Django is a Python package, installed with `pip install django`
• It turns an HTTP request into an HTTP response through a fixed, well-defined pipeline
• `django-admin startproject` scaffolds a runnable project in seconds
• It ships an ORM, an admin site, auth, sessions, and a template engine by default
• One project can hold many reusable "apps" — see project vs. application

Command

pip install django
django-admin startproject mysite
cd mysite
python manage.py runserver

Key features

• Model = data and business rules — a Python class mapping to a database table
• Template = presentation — HTML with placeholders, no business logic
• View = the glue — a function/class reading a request, using a Model, choosing a Template
• Django's own docs call this "MTV" but note it is very close to the well-known MVC pattern
• Confusingly, Django's "View" plays the role MVC calls the "Controller"

Command

# Model — models.py
class Article(models.Model):
    title = models.CharField(max_length=200)

# View — views.py
def article_detail(request, pk):
    article = Article.objects.get(pk=pk)
    return render(request, "article.html", {"article": article})

Key features

• ROOT_URLCONF names the module Django loads first, e.g. "mysite.urls"
• That module must define urlpatterns, a list of path()/re_path() entries
• path("articles/<int:year>/", view) captures a URL segment as a typed argument
• include("app.urls") lets one app own a whole prefix of routes, not just one path
• Django tries patterns top to bottom and calls the view for the first match

Command

from django.urls import path, include

urlpatterns = [
    path("admin/", admin.site.urls),
    path("articles/", include("articles.urls")),
]

Key features

• A view is any callable that takes a request and returns an HttpResponse (or subclass)
• Function-based views (FBVs) are plain functions — direct and explicit
• Class-based views (CBVs) package common patterns (list, detail, form) as reusable classes
• A view can also be `async def` for use under ASGI
• Raising Http404 inside a view is how Django returns a proper 404 response

Command

from django.http import Http404
from django.shortcuts import render
from .models import Article

def detail(request, pk):
    try:
        article = Article.objects.get(pk=pk)
    except Article.DoesNotExist:
        raise Http404("Article does not exist")
    return render(request, "articles/detail.html", {"article": article})

Key features

• class Name(models.Model): — every model subclasses Model
• Each class attribute (CharField, DateTimeField, ForeignKey, ...) becomes one column
• Django adds an `id` primary key automatically unless one is defined
• `makemigrations` then `migrate` turns a model change into a real schema change
• Model.objects is the manager — entry point for .filter(), .get(), .create()

Command

from django.db import models

class BlogPost(models.Model):
    title = models.CharField(max_length=200)
    content = models.TextField()
    created_at = models.DateTimeField(auto_now_add=True)

Key features

• A settings module is plain Python — variables, imports, even a for-loop, all legal
• DJANGO_SETTINGS_MODULE (e.g. "mysite.settings") tells Django which module to load
• Read settings via `from django.conf import settings`, never the module directly
• Django loads its own defaults first (global_settings.py), then overrides with yours
• DEBUG, ALLOWED_HOSTS, and SECRET_KEY are the settings that matter most before deploying

Command

export DJANGO_SETTINGS_MODULE=mysite.settings
python manage.py runserver
# or, one-off:
python manage.py runserver --settings=mysite.settings_dev

Key features

• {{ variable }} outputs a context value; supports dot lookup like {{ story.title }}
• {% if %}/{% endif %} and {% for %}/{% endfor %} are the core logic tags
• render(request, template_name, context) is the usual way a view produces the response
• The DTL is deliberately limited — no arbitrary Python expressions, by design
• {% load %} brings in tags/filters from an app, e.g. {% load static %}

Command

from django.shortcuts import render

def story_detail(request, pk):
    story = Story.objects.get(pk=pk)
    return render(request, "news/story_detail.html", {"story": story})

Key features

• forms.CharField, forms.EmailField, etc. — one class attribute per form field
• Unbound: Form() (no data) — for a blank/initial display
• Bound: Form(request.POST) — carries data to validate
• is_valid() runs every field's validation and returns True only if all pass
• cleaned_data holds the validated, type-converted result — read only after is_valid()

Command

from django import forms

class ContactForm(forms.Form):
    subject = forms.CharField(max_length=100)
    message = forms.CharField(widget=forms.Textarea)
    sender = forms.EmailField()
    cc_myself = forms.BooleanField(required=False)

Key features

• MIDDLEWARE (a setting) is an ordered list — order changes behavior, not just style
• Each middleware wraps get_response: code before get_response(request) runs on the way in
• Code after get_response(request) runs on the way back out, in reverse order
• Returning a response without calling get_response() short-circuits every inner layer
• AuthenticationMiddleware must come after SessionMiddleware — it reads the session

Command

def simple_middleware(get_response):
    # runs once, at server startup
    def middleware(request):
        # before the view / next layer
        response = get_response(request)
        # after the view / next layer
        return response
    return middleware

Key features

• `admin.site.register(Model)` is the minimum needed for a working CRUD page
• A ModelAdmin subclass customizes list_display, list_filter, search_fields, and more
• Requires `python manage.py createsuperuser` to create the first login
• The docs describe it as an internal management tool, not the site's public front end
• `@admin.register(Model)` is a decorator shortcut for the same registration

Command

from django.contrib import admin
from .models import Article

admin.site.register(Article)

Key features

• authenticate(request, username=, password=) verifies credentials, returns User or None
• login(request, user) attaches the user to the session — separate from authenticate()
• logout(request) clears all session data for the current request
• request.user is available on every request — an AnonymousUser instance if not logged in
• @login_required redirects unauthenticated visitors to LOGIN_URL

Command

from django.contrib.auth.decorators import login_required

@login_required
def dashboard(request):
    return render(request, "dashboard.html", {"user": request.user})

Key features

• SessionMiddleware must be in MIDDLEWARE for request.session to exist
• request.session behaves like a dict: request.session["key"] = value
• The cookie holds only a session ID — the data itself is stored server-side
• SESSION_ENGINE picks the backend: db (default), cache, cached_db, file, signed_cookies
• request.session.flush() clears the session and deletes the cookie entirely

Command

def post_comment(request, new_comment):
    if request.session.get("has_commented", False):
        return HttpResponse("You've already commented.")
    request.session["has_commented"] = True
    return HttpResponse("Thanks!")