Views¶

Health View¶

Health view of the confirm Django app.

class confirm.django.views.health.HealthView(**kwargs)¶

Extensible health view.

Returns a JSON summary of the system health. Every *_health property is evaluated as a health check: if it returns without raising, the check is healthy; if it raises, the check is unhealthy. A check may raise SkipHealthCheck to be skipped (left out of the report). Add your own checks simply by defining further *_health properties on a subclass.

A healthy response (status code 200) looks like:

{
    "status": "healthy",
    "message": "All checks are healthy.",
    "checks": {
        "database": "healthy"
    }
}

As soon as one check fails the overall status becomes unhealthy, the response has a 500 status code, the message concatenates the exception messages and an errors object (keyed by check) carries them individually:

{
    "status": "unhealthy",
    "message": "Checks unhealthy: connection refused",
    "checks": {
        "database": "unhealthy"
    },
    "errors": {
        "database": "connection refused"
    }
}

Note

When the endpoint should stay reachable without authentication (e.g. behind LoginRequiredMiddleware), expose it with the login_not_required() decorator.

property celery_health: None¶

Check Celery by verifying the broker connection and pinging the workers.

Skipped (via SkipHealthCheck) when the CELERY_APPLICATION setting is not defined, i.e. when the project does not use Celery.

property database_health: None¶: Check the default database by opening a cursor and running SELECT 1.

get(request: HttpRequest, *args, **kwargs) → JsonResponse¶

Evaluate every *_health check and render the result as JSON.

Returns a 200 response when all checks are healthy, otherwise 500. A check raising SkipHealthCheck is left out of the report.

exception confirm.django.views.health.SkipHealthCheck¶: Raised by a *_health check to signal that it does not apply and should be skipped — omitted from the report entirely, rather than counted as healthy or unhealthy.

Generic Views¶

List Views¶

Generic list view.

class confirm.django.views.list.ListView(**kwargs)¶

A ListView that uses GenericTemplateNamesMixin for generic template-name lookup, and names the object list in the context with the pluralised, snake-cased model name (see get_context_object_name()).

get_context_object_name(object_list) → str | None¶: Return the pluralised, snake-cased model name for the object list in the template context (or the explicit context_object_name if set).

Detail Views¶

Generic detail view.

class confirm.django.views.detail.DetailView(**kwargs)¶: A DetailView that combines GenericTemplateNamesMixin (generic template-name lookup) with SnakeCaseObjectNameMixin (snake-cased context object name).

Create Views¶

Generic edit views.

class confirm.django.views.create.CreateView(**kwargs)¶: A CreateView that combines GenericTemplateNamesMixin (generic template-name lookup) with SnakeCaseObjectNameMixin (snake-cased context object name).

View Mixins¶

Mixins for Django views.

class confirm.django.views.mixins.GenericTemplateNamesMixin¶

Mixin for Django generic views that adds fallback template lookup paths.

On top of the usual template_name, it also looks for app-specific and fully generic templates, so a set of shared generic/*.html templates can serve many models without a per-model template.

The lookup can be tuned with these optional class attributes; each is auto-detected when not set:

template_name_app: the app name (detected from the view’s module) template_name_subdir: the sub-directory (the snake-cased model name) template_name_doc: the document name (from template_name_suffix)

For a Question model in a polls app, a detail view resolves to:

polls/question/detail.html

polls/generic/detail.html

generic/detail.html

See get_template_names() for the exact resolution order.

get_template_names() → list¶

Return the template lookup paths, ordered from the most specific (template_name, then <app>/<subdir>/<doc>.html) to the fully generic generic/<doc>.html.

See the class docstring for how app, subdir and doc are resolved.

class confirm.django.views.mixins.SnakeCaseObjectNameMixin¶

Mixin for Django single-object views that names the object in the template context after its snake-cased model name.

A Question object thus becomes {{ question }} in the template, unless an explicit context_object_name is set.

get_context_object_name(obj: Model) → str | None¶: Return the snake-cased model name to use for the object in the template context (or the explicit context_object_name if set).