Djangoの組み込みのインクルードタグとカスタムインクルードタグの違いは何ですか?
ドキュメントを読みましたが、どちらも同じ目標を達成しているようです。つまり、テンプレートをレンダリングして、コンテキストまたは変数を渡します。
Djangoの組み込みのインクルードタグとカスタムインクルードタグの違いは何ですか?
ドキュメントを読みましたが、どちらも同じ目標を達成しているようです。つまり、テンプレートをレンダリングして、コンテキストまたは変数を渡します。
それらは異なる目的を果たします。タグには、既存のテンプレートのinclude
コンテンツ全体がそのまま含まれているだけです。カスタムインクルージョンタグは、コンテキストを関数に渡します。この関数には、コンテキストをテンプレートに渡す前に、コンテキストを操作するロジックを含めることができます。
たとえば、複数のページに表示されるパネルがあるかもしれません。パネルのテンプレートでは、コンテキストを介してパネルに渡される特定のクエリがいくつか必要です。パネルを含むページは、他の何かのためにそれらのコンテキスト変数を必要としません。タグ付きのパネルテンプレートを含める場合、パネルinclude
を含むすべてのビューにこれらのクエリを記述し、コンテキスト変数として渡す必要があります。
または、クエリを含むカスタムの包含タグを作成して、それらをパネルのテンプレートに渡すこともできます。カスタムインクルージョンタグを使用することで、パネルを含むすべてのビューでコンテキストを生成するためにコードを繰り返す必要がなくなります。私のビューには含まれるコードが少なくなり、パネルでのみ使用されるコンテキスト変数が乱雑になりません。
操作されていないコンテキストを単純に渡すカスタム包含タグはタグと同じであるという意味では正しいですがinclude
。
テンプレートを小さなファイルに分ける必要がありますか?インクルードタグを使用する(読みやすさと保守性およびDRYのために)
テンプレートをレンダリングする前に、さらにコードを含める必要がありますか?インクルージョンタグを使用します(データをさらにフェッチし、ビジネスロジックを追加します。これは、実際には別の小さなURLなしのビューのようなものです。テンプレート関数のようなものです)。
原則として、dgelとYardenSTの回答による指摘は正しいです。さらに、djangoのコードを調べると、これら2つのオプションのパフォーマンスを比較する方法についての優れた洞察が得られます。
デフォルトのテンプレートローダーを使用する場合、2つの間にまったく違いはありません。どちらも最終的にInclusionTag
render()
関数を呼び出し、次に関数を呼び出してLoader
get_contents()
、ファイルシステムからテンプレートファイルを開きます。render()
テンプレートforループで使用される場合にのみ、ファイルをキャッシュします。
ちなみに、 django.template.loaders.cached.Loaderを使用すると、パフォーマンスに違いが生じる可能性があります。
最後に、さまざまなビューにまたがる共通のコンテキストに包含タグを使用するというdgelの提案に関して、htmlマークアップが多くのビューにまたがる単一のベーステンプレートにある場合、包含テンプレートをレンダリングするためのわずかな余分なオーバーヘッドを回避することは非常に可能です。ContextMixinを使用します。これは、レンダリングの非常に一般的なシナリオです。基本テンプレートのメインメニュー。
に入る可能性のある実際の追加ロジックがない場合に、どのルートをinclude
取るのが最適かを見つけようとしていたときに、最近この質問に直面しました。inclusion tag
inclusion tag
そして、私inclusion tag
は次の理由でを選択します:
<!-- include -->
{% include "path/to/funky.html" with arg1=arg1 arg2=arg2 %}
vs
<!-- inclusion tag -->
{% funky arg1 arg2 %}
inclusion tag
、親ビューから変数を継承できず、奇妙なバグに対する回復力が高まります。