8

私は Django で大規模なソーシャル ネットワーキング アプリに取り組んでおり、特定のフロントエンド コンポーネントを何度も使用することを期待しています。多くの場合、カスタム コンポーネントに他のカスタム コンポーネントが含まれるように設計された機能があり、さらに小さなサブコンポーネント (ad無限）。通常、これらのコンポーネントはすべて動的に生成されます。私のコンポーネントが保守しやすく、明確なプログラミング インターフェイスを持つように、Django フレームワークでこれを設計するための最良の方法を見つけようとしています。グローバル コンテキストに大きく依存することは、これとは逆のように思えますが、ビューで一度にすべて実行することで、冗長なクエリを回避する利点が見られます。

カスタム インクルージョン テンプレート タグは、コンポーネントの実装に適しているように思えますが、高度にネストされたテンプレート タグがパフォーマンスの問題を引き起こす可能性があるのか​​、それとも構文解析アーキテクチャがこれを防いでいるのでしょうか? メイン ページ テンプレート、カスタム タグ、およびすべてをレンダリングするために必要なコンテキストをビュー レベルで自己文書化する最善の方法は何ですか? テンプレート コンテキストを設定するコードを適切に維持しようとするのは、ちょっとした悪夢だと思います。最後に、これらのコンポーネントの CSS を維持する最善の方法は何ですか?

ネストされたコンポーネントの設計を作成するための他の推奨アプローチを自由に提案してください。

4

2 に答える 2

2

私がこれまでに決めた解決策は、再利用可能なコンポーネントのセットとして包含タグ ライブラリを使用することです。ビューコードですべてのクエリを設定し、それらをコンテキストの事前設定で渡すことにできるだけ固執しています。テンプレートまたはタグライブラリコードで新しいクエリを生成する関数はありません。インクルージョン テンプレートにはアイテムのすべてのマークアップが含まれ、スタイルはメイン サイトのスタイルシートに入り、 SMACSSのガイドラインに従って、私のクラスを可能な限り汎用的かつ再利用可能に保ちます。DRY が必要とする場合にのみ、コンポーネントを包含タグにリファクタリングします。

最初に、包含タグ関数がタグ テンプレートで使用されるパラメーターを明示的に受け取るようにしました。

ページ テンプレート

<div>{% my_tag param1 param2 %}</div>

タグ ライブラリ

@register.inclusion_tag('myapp/tagtemplates/my_tag.html')
def my_tag(param1, param2):
    return {'param1': param1, 'param2': param2}

my_tag.html

<div>Blah: {{ param1 }}</div>
<div>Blip: {{ param2 }}</div>

...そして明らかに、ビューはコンテキストを設定します。

しかしtakes_context、タグ ライブラリでパラメーターを明示的に定義することを避けるために、代わりにパラメーターを使用することにしました。ドキュメンテーションで十分な利益を得られないため、繰り返しが多すぎます。これまでのところ、私のコンポーネントは十分に単純なので、タグ テンプレートを調べれば依存関係はかなり明確です。複雑なネストされたコンポーネントではこれが受け入れられないのではないかと心配していますが、必要な場所でタグ ライブラリ関数をいつでも冗長にすることができます。

メンテナンスの観点から、このセットアップに完全に満足しているわけではありません。どのコンテキスト データが不要になったかを手動で追跡する必要があるのは好ましくありません。衝突を避けるために CSS クラスに慎重に名前を付けなければならないという事実は好きではありません。

私が決定したことが本当にベストプラクティスであるかどうか確信が持てないので、私はまだ新しい解決策に対してオープンです。

于 2012-11-16T08:54:03.170 に答える
0

これは興味深い問題です。理想的には、レンダリングする前にデータベースからすべてのコンポーネントをプルする必要があります。しかし、階層を見ると、テンプレート タグを作成することは理にかなっています。これらのテンプレート タグは、適切なデータを取得します。この問題の目的のために、検索の局所性のためにデータベース クエリがキャッシュされると仮定します。

于 2012-11-15T12:26:04.703 に答える