コンテキスト プロセッサでできることはすべて、ミドルウェアでできるように思えます。では、コンテキスト プロセッサのポイントは何でしょうか。それらは単なるミドルウェアライトですか?
3 に答える
ミドルウェアは、Django の要求/応答処理へのフックとして低レベルで機能し、軽量です。フックは、リクエスト、レスポンス、ビュー、template_response、および例外処理で使用できます。フックは、ビューが処理する前にリクエストを変更する必要がある場合や、デバッグ目的でリクエストに関する情報をログに記録したり、Cookie をチェックしてローカルを設定したりする必要がある場合があります。
ミドルウェアの詳細をお読みください。
コンテキスト プロセッサは、コンテキストを変更するだけです。コンテキストは、テンプレートに渡される変数を使用したキーと値のマッピングです。コンテキスト プロセッサは、リクエスト オブジェクトを引数として取り、コンテキストにマージされる項目の辞書を返します。コンテキストは、ビューごとにテンプレートにレンダリングされ、コンテキスト プロセッサがマージされる他のすべてのものをアタッチします。これは、すべてのテンプレートで使用できるグローバル コンテキスト変数と考えることができます。
Context Processorsの詳細を参照してください。
どちらも非常に簡単に記述でき、それぞれの目的があります。以下は、ミドルウェアとコンテキストが典型的な django フローのどこに適合するかを示す図です。
ジャンゴのフローチャート
ユーザーがページをリクエストする
リクエストは、リクエストを操作または応答できるリクエスト ミドルウェアに到達します。
URLConffinds urls.py を使用して関連するビュー
ビュー ミドルウェアが呼び出され、リクエストを操作または応答する可能性があります
ビュー関数が呼び出されます
ビューは、オプションでモデルを介してデータにアクセスできます
モデルから DB へのすべての対話は、マネージャーを介して行われます
ビューは必要に応じて特別なコンテキストを使用できます
コンテキストは、レンダリングのためにテンプレートに渡されます
コンテキスト プロセッサは、テンプレートに追加データを提供するために使用されます。ミドルウェアは、リクエスト/レスポンス オブジェクトを傍受し、意味のある方法でそれらを変更する (または他の動作をトリガーする) ためのものです。
それらは、異なるコンテキストの異なるレベルのスタックで機能します。通常、フレームワークのスタックを完全にオーソドックスに保つのは困難です。特に、Django のような Web フレームワークが処理するのはリクエストとレスポンスだけです。はい、テンプレートをレンダリングするときに context_processor によって context.user の代わりに request.user を使用できます。ただし、テンプレートでのみ使用され、すべてのリクエストで設定される属性が必要ない場合があります。
また、decorator はビューレベルの操作に関してはミドルウェアより柔軟ですが、decorator-lite とは言い難いミドルウェアです。コンテキスト プロセッサを割り当てテンプレート タグとして扱いたいのですが、自動的に読み込まれます。