Django / Request and data foundations / Lesson 1

Projects, settings, and the request cycle

Locate responsibilities in a Django application and distinguish its project configuration from reusable apps and local demonstrations.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

A project coordinates application responsibilities
A response carries status, headers, and content
Record the execution context when debugging

A project coordinates application responsibilities

Django coordinates URL resolution, request processing, views, templates, forms, models, and supporting middleware. A project supplies the settings and entry points for one deployed application, while an app groups a feature or reusable domain capability. These are organizational boundaries, not automatic security boundaries. A small training app can serve a workshop catalog without knowing how its host is deployed. Keep the domain rules separate from the mechanics of receiving HTTP so they can be tested independently. A framework provides useful defaults, but neither a generated directory nor a successful welcome page proves that authorization, production configuration, or data recovery is complete.

Use a declared and supported baseline

This course targets Django 5.2 LTS and tests local examples with Django 5.2.18 on Python 3.12.3. Official release information reviewed on the course date also lists newer feature series; this is a deliberate supported baseline rather than a claim that 5.2 is newest. Read versioned documentation and keep patch maintenance separate from copying an arbitrary tutorial. A virtual environment isolates package choices, not hostile code. Complete examples configure their own synthetic settings and in-memory SQLite connection, never import a project settings module, and run in fresh processes. Application fragments explicitly require their surrounding project and remain non-runnable.

A response carries status, headers, and content

The first example constructs an HttpResponse in the isolated settings context. Its status, media type, and body are separate aspects of the HTTP contract. A browser rendering the body attractively does not prove that the status or caching headers are appropriate. Use an explicit content type when returning plain text or structured data, and choose status codes according to the operation’s actual outcome. Returning the word “error” with status 200 can mislead clients and monitoring. Django response objects can be inspected without opening a listening server, which makes small deterministic examples useful for learning the boundary safely.

python Isolated executable example

from django.conf import settings
settings.configure(
    SECRET_KEY="synthetic-course-key",
    USE_I18N=False, USE_TZ=True,
    INSTALLED_APPS=[],
    DATABASES={"default": {"ENGINE": "django.db.backends.sqlite3", "NAME": ":memory:"}},
    DEFAULT_AUTO_FIELD="django.db.models.AutoField",
    ALLOWED_HOSTS=["testserver"],
)
import django
django.setup()

from django.http import HttpResponse
response = HttpResponse("Workshop ready", content_type="text/plain", status=200)
print(response.status_code)
print(response.content.decode("utf-8"))

Expected output

200
Workshop ready

The object is inspected locally without opening a socket. Status and text are checked independently.

Trace a request without a network service

The second example uses RequestFactory to create a synthetic request and calls a simple view directly. The view reads a query parameter and returns a response. RequestFactory does not automatically run URL routing, session middleware, authentication middleware, or CSRF checks; later client tests exercise more of that stack. This distinction prevents a unit-style view test from being mistaken for complete browser evidence. Request inputs are untrusted even when the test uses a friendly value. A real view must validate the values it uses and enforce access independently of what a query string happens to request.

python Isolated executable example

from django.conf import settings
settings.configure(
    SECRET_KEY="synthetic-course-key",
    USE_I18N=False, USE_TZ=True,
    INSTALLED_APPS=[],
    DATABASES={"default": {"ENGINE": "django.db.backends.sqlite3", "NAME": ":memory:"}},
    DEFAULT_AUTO_FIELD="django.db.models.AutoField",
    ALLOWED_HOSTS=["testserver"],
)
import django
django.setup()

from django.http import HttpResponse
from django.test import RequestFactory

def greeting(request):
    name = request.GET.get("name", "Guest")
    return HttpResponse(f"Hello {name}", content_type="text/plain")

request = RequestFactory().get("/greet/", {"name": "Mira"})
print(greeting(request).content.decode("utf-8"))

Expected output

Hello Mira

RequestFactory supplies only a synthetic request here. The direct call does not claim routing or middleware execution.

Record the execution context when debugging

A reproducible report includes Django and Python versions, the settings source, request method and path, expected status, and actual exception or response. Redact secrets and personal data rather than publishing entire environments or settings dumps. Inspect the earliest failing boundary: an import failure, URL miss, validation rejection, and database exception require different fixes. Do not start by changing deployment configuration when the minimal view calculation is wrong. Keep local development tools separate from production serving; the development server is for development and does not establish a secure or scalable deployment. The remaining lessons build each boundary on this explicit foundation.

Common errors and fixes

A view test is mistaken for a full request test

Why it happens: The view was called directly without middleware.
How to fix it: Choose the test boundary explicitly.
Prevent it next time: Document which layers every test executes.

A local example loads the working database settings

Why it happens: It imports the project settings module implicitly.
How to fix it: Configure a separate synthetic test context.
Prevent it next time: Verify settings and database targets before execution.

Clients see success for a failed operation

Why it happens: The body says error but status remains successful.
How to fix it: Return a status matching the documented outcome.
Prevent it next time: Assert status and content separately.

Check your understanding

1. Which layers are omitted by directly calling a view with RequestFactory?

Show worked solution

URL resolution and middleware are not automatically executed. Session, authentication, and CSRF state must not be assumed present. Use this narrow boundary for view logic, then add client, integration, or browser evidence for the other contracts rather than inflating the meaning of one test.

2. Create a safe minimum report for a response that differs between environments.