Django プロジェクト¶

core において、Django プロジェクトはセッティングファイル以外を必要としません。このプラクティスにおいては、大体のプロジェクトが次のような事項から成っています。

セッティング
URLconf
WSGI ファイル
ローカルアプリケーション
テンプレート
静的メディアファイル
manage.py

セッティング¶

settings モジュールは Django プロジェクトにおいて必須です。一般的に、 settings.py という名前で、あなたの作ったプロジェクトのルートに存在します。

複数環境でのセッティングの扱い¶

Django での startproject コマンドは settings.py ファイルを 1 つ作成します。もしあなたが Django に触れて間もない場合、こつこつ学習する間はずっとこのファイルと一緒です。本番サイトのデプロイを始めたり、複数人で開発作業をする際に、複数のセッティングファイルをメンテナンスすることの恩恵を実感することでしょう。例えば、本番ではなく、ローカル環境で、よくある DEBUG 付きの実行をしたい場合などです。

複数セッティングを扱うにはいくつもの方法があります。次に挙げる要件に合わせて、好きな方法を選んでください。

全ての重要な セッティングファイルはバージョン管理されている 。もし本番サイトでセッティングが変わったときは、あなたは誰が、いつ、その変更を加えたのかを知りたいと思うでしょう。
全てのセッティングが common base から継承されている 。もしあなたが django-debug-toolbar を INSTALLED_APPS に追加したいときは、全ての INSTALLED_APPS を再定義することなしに、それを行うべきです。

もしそういったことを考慮したくない場合は、シンプルに我々の Django プロジェクトテンプレートを、新しくプロジェクトを始めるときに使ってください。そのプロジェクトテンプレートでは、一歩踏み出すための複数プロジェクトをサポートする準備が整っています

django-admin.py startproject --template=https://github.com/lincolnloop/django-layout/tarball/master -e py,rst,example,gitignore my_project_name

参考

Django’s Split Settings Wiki: 複数セッティングを扱う例があります

ファイルパスの扱い¶

あなたのセッティングの一つの機能は、 Django に静的メディアファイルやテンプレートを探す場所を知らせることです。おおよその場合は、それらは既にあなたのプロジェクトの中に存在して使用されています。もしそうであれば、あなたのために Python に絶対パスを生成させてください。こうすることで、異なる環境間でも、あなたのプロジェクトをポータブルに利用することができます。

import os
DIRNAME = os.path.dirname(__file__)
# ...
STATIC_ROOT = os.path.join(DIRNAME, 'static')

URLconf¶

デフォルトでは、あなたのプロジェクトのルートに URLconf を urls.py という名前で見つけることができるでしょう。これはリクエストがあなたのプロジェクトでどのようにルーティングされるかを定義しています。

シンプルに保つ¶

あなたのプロジェクトの URLconf は、可能であればいつでも、あなたのアプリケーションから URLconf 群をシンプルにインクルードすべきです。そうしておけば、あなたが作ったアプリケーションロジックやプロジェクトを、ポインターとしてシンプルに提供できます。

参考

Django URL dispatcher documentation: URLconf 群をインクルードする例

複数環境のための URLconf 群の扱い¶

あなたのセッティングモジュールのように、結局は、異なる URLconf 群にまたがって実行したい場面に出くわすことでしょう。あたなは多分、 admin をローカルで使いたいでしょうが、一度デプロイするだけでは終わらないでしょう。Django はこのための簡易な手段を既に提供しており、 ROOT_URLCONF セッティングを一緒に使うことで実現できます。

これは基本的に、複数セッティングによるものと同じシナリオです。同じことをする、次のような解決法もあります:

myproject
  ...
  settings/
        __init__.py
        base.py         <-- 全ての環境で共有される
        def.py
        production.py
  urls/
    __init__.py
        base.py                 <-- 全ての環境で共有される
    dev.py
    production.py
  ...

参考

我々の django-layout テンプレート

WSGI ファイル¶

WSGI ファイルは、あなたのプロジェクトを web で公開するために必要な情報を WSGI サーバーに教えます。Django のデフォルトの wsgi.py はおおよそのアプリケーションにとって十分な内容になっています。

ローカルアプリケーション¶

ローカルアプリケーションは、あなたのプロジェクトにドメイン固有な Django アプリケーションです。それらはおおよそ、プロジェクトモジュールの中に存在しており、あなたのプロジェクトに密に関係しており、その外側ではほとんど利用されないでしょう。

ローカル vs. サードパーティ¶

数百 [1] のオープンソース Django アプリケーションが利用可能です。車輪の再発明をする前に、既に他の誰かが、あなたが解決しようとしてる問題を解決していないか、 Google または Django Packages で検索し、確認しましょう。もし解決してくれそうなものを見つけたら、あなたのプロジェクトコードに書き入れる のではなく 、代わりに、あなたの環境の pip requirements に追加しましょう。

[1]	http://djangopackages.com/categories/apps/

名前空間¶

ローカルアプリケーションがどのようにあなたのプロジェクトに取り込まれるべきかは、 Django コミュニティ [2] で継続的に議論されています。幸い Django 1.4 のリリースで、デフォルトの manage.py は今後はもう PYTHONPATH [3] を変更しないので、問題が少なくなりました。

Lincoln Loop においては、我々はプロジェクトの名前空間内にプロジェクトアプリケーションを入れます。これにより、グローバルの名前空間の汚染を防ぎ、名前が衝突する潜在性を回避します。

[2]	django-developers メーリングリストでの、チュートリアルにおける、プロジェクトの名前空間についての議論

[3]	Django 1.4 での manage.py の変更点

テンプレート¶

場所¶

テンプレートはおおよそ、2 つの場所、アプリケーションか、プロジェクトのルート階層のうち、どちらかに存在します。我々のおすすめは、あなたが複数のプロジェクトを自分のアプリケーションに含めない限り(または “再利用可能な” オープンソースのアプリケーションとして開発しない限り)、全てのあなたのテンプレートを、プロジェクトのテンプレートディレクトリに保持することです。その場合、アプリケーション中のサンプルテンプレートのセットを含めて公開するのに有用で、その状態のままで動かすこともできますし、他の開発者へのサンプルとして提供することもできます。

名前付け¶

Django のジェネリックビューはテンプレートに名前付けするための優れたパターンを提供します。Django に既にあるデザインパターンに従うことは、次の 2 つの理由で有用です。

それらは、よく考え抜かれていますし、よくテストもされています
あなたの Django コードを使う新しい開発者にとって、コードを読みやすくします。

大体のジェネリックビューテンプレートは次の形式で名前付けされます

[application]/[model]_[function].html

例えば、自分の連絡帳 (address_book application) にある全ての連絡先 (Contact model) を表示するリストのテンプレートを作成する際、私は次のテンプレートを使います

address_book/contact_list.html

同じようなものとして、連絡先の詳細ビューでは次のものを使います

address_book/contact_detail.html

とは言え、毎回、あなたが作ったテンプレートが、一つ一つのモデルにぴったりと対応付け出来るわけではないでしょう。それらのケースでは、名前付けにおいて、あなた自身で頑張って行かなければいけません。それでも、そのテンプレートは、アプリケーションと同じ名前のディレクトリの中にはあるはずです。

埋め込みタグや、部分テンプレートをレンダリングするような、その他多くの機能を使う場合は、アプリケーションテンプレートディレクトリ内の includes ディレクトリにそれらを保持するようにしてください。例として、もし私が、連絡帳アプリケーションの中の連絡用フォームの埋め込みタグを設定しているとしたら、次のようにテンプレートを作ったことでしょう。

address_book/includes/contact_form.html

テンプレートファイルは必ず html の拡張子を付けなければいけないという制限は (もはや) ありません。もし何か他のファイル形式 (プレーンテキスト, JSON, XML, その他) をレンダリングする際、あなたのテンプレートファイルの拡張子は、生成するコンテンツの拡張子と一致させておけば良いでしょう。

静的メディアファイル¶

CSS, 画像, JavaScript, Flash などの静的メディア (あなたのサイトに必要な、動的じゃない全てのコンテンツ) は、ユーザー側で生成されるコンテンツ、それと、あなたのサイトをレンダリングするのに必要なメディアファイル、の 2 つに分けられます。このベストプラクティスは、それらを、あなたのアプリケーションの中にあるもの、それと、バージョン管理システムの中にある あなたの 静的メディアファイルのこととして書いています。確かに、自分が抱えるユーザーがアップロードしたものが、一箇所に固るのは我々も望みません。というわけで、我々はいつも django.contrib.staticfiles [4] を使います。

その他の巧妙な機能に加えて、 staticfiles は、静的ファイルがローカルマシン上にあったり、本番システム上のローカルじゃないストレージ内にあったりするどちらの場合でも、静的ファイルを適切に設置する static テンプレートタグ [5] を提供します。この仕組みは、ユーザー生成コンテンツを管理する MEDIA_URL と MEDIA_ROOT を残します。

参考

静的ファイルと Django について

[4]	https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/

[5]	https://docs.djangoproject.com/en/dev/ref/contrib/staticfiles/#std:templatetag-staticfiles-static