app1、app2、app3など、いくつかのアプリを含むdjangoプロジェクトpro1があります。すべてのアプリのブロックを含む最上位のテンプレートを表示したいと思います。
example_base_template.html:
[header /]
[left nav bar]{{ app1 rendered template }}[/left nav bar]
[right nav bar]{{ app2 rendered template }}[/right nav bar]
[center section]{{ app1 main functionality template }}[/center section]
[footer]{{ app3 rendered template }}{{ app4 rendered template }}[/footer]
これらのアプリ テンプレートはすべて動的で、DB を使用します。最も適切でエレガントな方法でそれを行う方法は? それとも、4 つの異なるビューを 1 つの URL に接続する方法が問題なのでしょうか?
{% include %}タグを使用できます。しかし、それはあまり役に立ちません。より良い解決策は、必要なテンプレートと機能を備えたカスタムの包含タグを作成することです。
(単純な方法で) 複数のビューを 1 つに混在させることはできません。そのかなりのdjangoソリューションにタグを付けてみてください。
これは、含めたいアプリケーションごとにカスタム テンプレート タグを作成することで実現しました。最初は、テンプレート タグがハード コードされた html を返しただけでした。後で、タグが独自のテンプレート フラグメントをロードできることがわかりました。また、かなりうまく機能する一般的な最新のコンテンツ タグであるスニペットもどこかにありました。
これと同様の問題が発生しました。重要なのは、正しいデータをコンテキストに取り込むことです。私たちが行ったのは、各ビューのデータ作成/コンテキスト入力を個別のコンテキスト構築ルーチンに分割することでした。元のビューは、それぞれのルーチンを呼び出してから、テンプレートをレンダリングするだけです。複合ビューは、各コンテキストビルダーを呼び出してから、マスターテンプレートをレンダリングします。マスターテンプレートには、サブテンプレートが含まれます。
ここで、Djangoテンプレートシステムで少し問題が発生しました。テンプレートフラグメントをキャッシュしていましたが、これらのフラグメントの一部は、生成に非常にコストのかかるデータを取得していました。フラグメントが古くない場合、私たちは間違いなくその作業をしたくありませんでした。しかし、必要であることがわかるまで作業を遅らせることは、テンプレート内にいることを意味し、次のようになります。
呼び出し可能オブジェクトが機能する必要がある理由は、カリー化された関数、つまり、パラメーターの一部（またはすべて）がすでに指定されているが、まだ呼び出されていない関数を渡すことができるためです。したがって、ビュー（またはこの場合はコンテキストビルド）は、完全に指定された関数をカレーできる必要があります（テンプレート自体にパラメーターを渡すことはできません）。これにより、必要なときにテンプレートが呼び出し可能オブジェクトを呼び出すことができます。データ、そして離れて行きます。
これには2つの別々のアプローチを取りました。
このサイトを作成してから、遅延データプロデューサーとしてジェネレーターを使用することで解決できた可能性があることを学びました。ジェネレーターはカリー化された関数のように機能しますが（セットアップに任意のパラメーターを渡すことができるという点で）、テンプレートエンジンはそれらを単なる別のイテレーターと見なします。このテーマに関する素晴らしいチュートリアルがあります。注：ジェネレーターは配列ではなく、一度しか使用できないため、ロジックの一部を微調整する必要がある場合があります。
次回は、 jinja2テンプレートを使用して、Djangoのテンプレートを使用するのをやめると思います。
多くの再利用可能なアプリ (特にPinaxプロジェクトに選択されたアプリ) は、カスタム テンプレート タグを使用してコンテンツを挿入する方法の優れた例として役立ちます。DjangoCon 2008 での James Bennett の講演も役立つかもしれません。