大規模なdjangoプロジェクトをレイアウトする最良の方法は何ですか? チュートリアルでは、アプリ、モデル、およびビューをセットアップするための簡単な手順が提供されますが、アプリとプロジェクトをどのように分割する必要があるか、典型的なプロジェクト内のアプリ間でどの程度の共有が許容/必要であるかについての情報はほとんどありません (明らかに、これは主にプロジェクト) および一般的なテンプレートを保持する方法/場所。
特定のプロジェクト レイアウトが別のプロジェクト レイアウトよりも優れている理由について、例、提案、説明がある人はいますか? 特に、多数の単体テスト (実際のコード ベースのサイズの 2 ～ 5 倍) の組み込みと、文字列の外部化/テンプレートに関心があります。
主なガイドラインは、他の大規模なコード プロジェクトと同様です。アプリは、明確に定義された単一の責任に対処する必要があります。「アプリケーション」という名前は誤称です。Django アプリは、プラグインして実際のアプリケーションを作成できる再利用可能なコンポーネントと考える必要があります。各アプリのテストは、そのアプリ内に含める必要があります。アプリは可能な限り互いに分離する必要がありますが、明らかに依存関係が存在するため、依存関係グラフをできるだけシンプルで健全な状態に保つことを目標にする必要があります。
私は、プロジェクトのすべてのテンプレートを単一のプロジェクト全体のテンプレート ディレクトリの下に保持し、アプリごとにサブディレクトリを保持することを好みます (アプリごとにテンプレート サブディレクトリを使用することは、アプリ間のテンプレート名の衝突を回避するため、Django では非常に強力な規則です)。 . プロジェクト全体で 1 つのテンプレート ディレクトリを使用する理由は、テンプレート、テンプレート継承ツリー、およびブロック名がプロジェクト固有のものになる可能性があるためです。そのため、任意のプロジェクトにプラグインできる "既定の" アプリ テンプレートを提供することは困難です。基本的なサイト全体のテンプレートとそれらが定義するブロックの標準的な命名規則に落ち着く試みがいくつかありましたが、私はまだ標準が出現するのを見たことはありません ( Pinaxでのやり方はおそらく私たちが持っている方法に最も近いものです)標準）。
「文字列の外部化」に関して、i18n と l10n を意味する場合、Django はそれを強力にサポートしており、.po ファイルを配置する標準的な場所もあります - docsを確認してください。
Zachary のレイアウトは非常に便利であることがわかりました Zachary Voase のブログ » Django プロジェクトの規約、再訪。
このページは、私の質問のいくつかにうまく対処しています: http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/
具体的には：
- カスタム テンプレート タグまたはフィルターを定義するには、アプリケーションのディレクトリに templatetags というサブディレクトリを作成する必要があります。このサブディレクトリには、Python モジュールとしてインポートできるように __init__.py という名前のファイルが含まれている必要があります。
- Django のテスト フレームワークによって自動的に認識される単体テストを定義するには、tests という名前のモジュール (tests.py という名前のファイルまたは tests という名前のディレクトリ) に配置します。テスト フレームワークは、そのモジュール内の任意の doctest も検索しますが、それらの推奨される場所は、もちろん、テストするように設計されたクラスまたは関数の docstring です。
- アプリケーションのインストール直後に実行されるカスタム SQL を提供するには、アプリケーションのディレクトリ内に sql というサブディレクトリを作成します。ファイル名は、操作対象のテーブルを持つモデルの名前と同じにする必要があります。たとえば、Entry という名前のモデルを含む weblog という名前のアプリがある場合、アプリのディレクトリ内のファイル sql/entry.sql を使用して、エントリ テーブルが作成されるとすぐにデータを変更または挿入できます。
tests.py と tests (ディレクトリ) に関する注意事項は、モデルにも当てはまります。これは、1 つのファイルに対して多くのテスト (またはモデル) を作成するという問題に対処するのに役立ちます。
アプリ/プロジェクトの内訳の例/提案、およびうまく機能する大きなdjangoサイトを引き続き見たいと思います。
Pinax プロジェクトは、簡単にプロジェクトにまとめることができる小さな再利用可能なアプリのアイデアに基づいて構築されています。彼らはCloud 27プロジェクトをデモ プロジェクトとして使用しました。
私が取り組んでいる Django プロジェクト (Basie と呼ばれます。これは 0.1 より前なので、まだリンクはありません) は Pinax モデルに従おうとしていますが、これまでのところかなりうまく機能しています。
私はこのテーマに関するRandallDeggesの投稿が本当に好きです。彼は設定ファイルを接着する方法についての情報を省略していますが、リンクできるようになるという投稿がありますが、今のところ、誰でも私のリポジトリをチェックして、readmeに方向性を含めることができます。
私の現在のレイアウトは、自分のサイトのテスト バージョンが必要なためです。これは、サイトごとに 2 つのプロジェクトを用意することを意味します。それぞれ異なる構成が必要であり、すべてのアプリケーションをプロジェクトから移動する必要があるためです。
$APP_ROOT/devel と $APP_ROOT/prod という 2 つのフォルダーを作成しました。これらにはすべてのアプリが含まれます。ソース管理 (私の場合は git) を使用して、開発中のアプリを HEAD リビジョンで使用していますが、製品中のアプリは PROD タグにロックされています。テンプレートには、アプリと同じレイアウトの独自のフォルダーもあります。
これで、すべての開発を devel-apps フォルダーとそれに対応する template-folder で行うことができます。満足できるものができたら、そのリビジョンにタグを付けて製品を更新します。