Django の組み込みビューのいくつかは、 ビューを記述する や他のドキュメントで説明されています。
\nプロジェクトの静的アセット以外にも、利便性のために、ローカル開発で Django に配信させたいファイルがあるかもしれません。 serve() ビューを使えば、任意のディレクトリに配信できます。(このビューは本番環境では 使えない ので、開発の補助としてだけ使ってください。本番環境では実際のフロントエンド Web サーバを使ってこれらのファイルを配信してください)。
最もありそうな例は、 MEDIA_ROOT にあるユーザがアップロードしたコンテンツです。 django.contrib.staticfiles は静的アセット用で、ユーザがアップロードしたファイルに対する組み込みの処理はありませんが、 URLconf に次のような記述を追加することで、 Django に MEDIA_ROOT を配信させることができます:
from django.conf import settings\nfrom django.urls import re_path\nfrom django.views.static import serve\n\n# ... the rest of your URLconf goes here ...\n\nif settings.DEBUG:\n urlpatterns += [\n re_path(\n r"^media/(?P<path>.*)$",\n serve,\n {\n "document_root": settings.MEDIA_ROOT,\n },\n ),\n ]\nこのコードは MEDIA_URL の値が 'media/' であると仮定しています。これは serve() ビューを呼び出して、 URLconf からのパス (必須) と document_root パラメータを渡します。
この URL パターンを定義するのは少し面倒なので、 Django には小さな URL ヘルパー関数 static() が同梱されています。この関数は MEDIA_URL のようなプレフィックスと、 'django.views.static.serve' のようなビューへのドットパスをパラメータとして受け取ります。その他の関数のパラメータは透過的にビューに渡されます。
Django には HTTP エラーを処理するためのビューがデフォルトでいくつか付属して います。これらを独自のカスタムビューで上書きするには、 エラービューをカスタマイズする を参照してください。
\nビュー内で Http404 を発生させると、 Django は 404 エラーの処理に特化した特別なビューを読み込みます。デフォルトでは django.views.defaults.page_not_found() というビューで、"Not Found" メッセージを表示するか、ルートテンプレートディレクトリにテンプレート 404.html を作成した場合、それを読み込んでレンダリングします。
デフォルトの404ビューはテンプレートに2つの変数を渡します。request_path はエラーの原因となった URL で、exception はビューのトリガーとなった例外の有用な表現です (たとえば、特定の Http404 インスタンスに渡されたメッセージなど)。
404ビューには以下の3つの注意点があります:
\n404 ビューは、 Django が URLconf 内の正規表現を全てチェックしてもマッチしない場合にも呼び出されます。
404 ビューには RequestContext が渡され、テンプレートコンテキストプロセッサが提供する変数 (たとえば MEDIA_URL) にアクセスできます。
もし DEBUG が True に設定されている場合(設定モジュール内)、404ビューは使用されず、代わりに URLconf がデバッグ情報と共に表示されます。
同様に、Django はビューコードで実行時エラーが発生した場合、特別なケースの動作を実行します。ビューで例外が発生した場合、 Django はデフォルトで django.views.defaults.server_error というビューを呼び出します。このビューは "Server Error" というメッセージを表示するか、ルートテンプレートディレクトリにテンプレート 500.html を作成した場合、それを読み込んでレンダリングします。
デフォルトの500ビューは 500.html テンプレートに変数を渡さず、空の Context でレンダリングされ、追加エラーの可能性を減らします。
もし DEBUG が True に設定されている場合 (設定モジュールで)、500 ビューは使用されず、代わりにトレースバックがデバッグ情報と共に表示されます。
404 や 500 のビューと同じように、 Django には 403 Forbidden エラーを扱うビューがあります。ビューで 403 例外が発生した場合、 Django はデフォルトで django.views.defaults.permission_denied というビューを呼び出します。
このビューはルートテンプレートディレクトリにあるテンプレート 403.html を読み込んでレンダリングします。このファイルが存在しない場合は、代わりに RFC 9110 Section 15.5.4 (HTTP 1.1 仕様) に従って "403 Forbidden" というテキストを配信します。テンプレートコンテキストは exception を含んでおり、これはビューのトリガーとなった例外の文字列表現です。
django.views.defaults.permission_denied は PermissionDenied 例外がトリガーとなります。ビューでアクセスを拒否するには、次のようなコードを使用します:
from django.core.exceptions import PermissionDenied\n\n\ndef edit(request, pk):\n if not request.user.is_staff:\n raise PermissionDenied\n # ...\nDjango で SuspiciousOperation が発生すると、 Django のコンポーネントで処理されるかもしれません (たとえばセッションデータのリセットなど)。特に処理されない場合、 Django は現在のリクエストをサーバエラーではなく「不正なリクエスト」と見なします。
django.views.defaults.bad_request は server_error ビューとよく似ていますが、エラー状態がクライアント操作の結果であることを示すステータスコード 400 を返します。デフォルトでは、例外メッセージにファイルシステムのパスのような機密情報が含まれている可能性があるため、ビューのトリガーとなった例外に関係するものはテンプレートコンテキストに渡されません。
また、bad_request ビューは DEBUG が False のときだけ使用されます。