related_name
リレーション先のオブジェクトから逆参照するときに使われる名前

verbose_name
人間用のわかりやすい名前

プロジェクトについて

大雑把にいうと「Djangoで動くウェブサイト」のこと。
また、プロジェクトは本質的にはPythonのパッケージ（init.pyファイルの入ったディレクトリ内に.pyファイルなどを収めた階層構造）に過ぎません。
通常、プロジェクトを作成する際はDjangoのインストール時に同時にインストールされるdjango-adimin.pyスクリプトを用いる。
プロジェクトディレクトリには下記の４つのファイルが作成されます。

_init.py

プロジェクトをpythonにパッケージとして認識させるためのファイル。このファイルがあると、プロジェクト下に置いたモジュールファイルを《ex: import mysite.module 》のようにimportできます。

manage.py

プロジェクトを管理するためのスクリプトです。django-admin.pyと同じ機能を備えていますが、起動時にプロジェクト固有の設定が読み込まれます。

settings.py

プロジェクト全体の設定を記述するためのファイルです。

urls.py

URLConfと呼ばれるURLのパターンとビューを関連付けるファイルです。
プロジェクトディレクトリ直下にあるURLConfはルートURLConfと呼ばれます。

プロジェクトを作成したら、以後の管理操作はdjango-admin.pyに代わってmanage.py で行います。

アプリケーションについて

アプリケーションの作成はstartappコマンドで行います。アプリケーションを作成すると、アプリケーションディレクトリには下記の３つのファイルが作成されます。

_init.py

プロジェクト同様、このディレクトリをpythonにパッケージとして認識させるためのファイル。

models.py

データモデルの定義を行うためのファイルです。このファイル上でデータモデルを定義しておくと、Djangoが自動的にデータベースにモデルを組み込みます。

views.py

ビューを定義するためのファイルです。

モデルについて

モデルの組み込み

モデルを作成したらこのモデルを今のプロジェクトに組み込み、Djangoに「モデル（データベース）作ったよー」と認識させる必要があります。アプリケーション内のモデルをプロジェクトに組み込むには、settings.pyのINSTALLED_APPSにアプリケーションへのモジュールパスを文字列で指定します。

モデルを操作する

モデルを使うには、まずモデルモジュールをインポートします。
from todo.models import todo

新しいモデルのインスタンスを生成するには、モデルクラスを呼び出します。
＞＞＞ t1 = Todo()
＞＞＞ t1

新たに作成したインスタンスをデータベースに保存するにはsave（）メソッドを呼び出します。
逆に上記で新たに保存したインスタンスをデータベースから呼び出すには、【モデルクラスのobjects】という属性を使います。
objects属性はオブジェクトマネージャと呼ばれ、データベースから指定した条件に合ったオブジェクトを取りだすためのメソッドを備えています。

単一のインスタンス（レコード）を取り出すには、get()メソッドを使います。
t1 = Todo.objects.get(id=1)
すべてのインスタンス（レコード）を取り出すには、all()メソッドを使います。
この際、戻り値は１つのレコードではなくすべてのレコードが反映された「リストオブジェクト」であることに注意してください。
t1 = Todo.objects.all()
条件に合ったレコードを取り出したいときはfilter()メソッドを使います。
Todo.objects.filter(title='foo')

all()メソッドやfilter()メソッドは実際には__クエリセット__というオブジェクトを返しています。
クエリセットはイテレータで対話シェルで表示するとリストを返します。
クエリセットはオブジェクトマネージャと同じようなメソッドを備えています。
すなわち__all()やfilter()が返したクエリセットに対してさらにfilter()やget()を呼び出せるのです。__
これによって、モデルインスタンスを段階的に絞り込んだり、「絞込途中のクエリセット」を変数に格納して使いまわしたりできます。

ミドルウェア

サイトによっては、セッション管理を行ったり、最終更新時刻などのヘッダ情報を追加したりなど、すべてのリクエストやレスポンスに対して一律の処理を行いたい場合があります。こうした処理を実現するために、Djangoにはミドルウェアと呼ばれる仕組みがあります。ミドルウェアを作成して登録しておくと、Djangoはリクエストやレスポンスの処理時にミドルウェアを実行します。たとえば、Djangoには基本的な認証の仕組みがありますが、その背後には組込の認証ミドルウェアがあり、リクエストヘッダとデータベースを使ったユーザー認証を実現しています。

ビュー関数

説明１
ビュー関数、あるいは単にビューとは、簡単にいえばウェブリクエストを引数にとり、ウェブレスポンスを返す関数です。レスポンスはウェブページを表す HTML コンテンツでもよいし、リダイレクトでも、 404 エラーでも、 XML ドキュメントでも、画像でも、何でもかまいません。ビューの中には、レスポンスを生成する上で必要なロジックを自由に書けます。

from django.http import HttpResponse
def hello(request):
message = "

Hello,Django!
return HttpResponse(message)

各ビューには二つの役割があります
①リクエストされたページのコンテンツを含む HttpResponse オブジェクトを返す
②Http404 のような例外の送出です。それ以外の処理はユーザ次第です。

説明２
Djangoのビューは必ず第一引数にリクエストオブジェクトを取ります。リクエストオブジェクトとは、「ユーザーから送信されたHTTPリクエストオブジェクトの情報にアクセスするための」オブジェクトです。
また、冒頭でdjango.http モジュールから HttpResponse クラスを import しています。
django.http モジュールはHTTPレスポンスに関するクラスや関数を定義しているモジュールで、
HttpResponse クラスはコンテンツを伴う通常のHTTPレスポンスを表すクラスです。
Djangoのビュー関数から、正常なレスポンスを返すには必ずレスポンスオブジェクトを作成して返さなければなりません。
このレスポンスオブジェクトも、リクエストオブジェクトと同様、HTTPレスポンスメッセージの様々な情報にアクセスしたい場合に利用できます。
上記のhello関数では、HttpResponse クラスに簡単なHTMLを渡してレスポンスオブジェクトを作成し、これをそのままreturn文で返しています。これによって、Webサーバはユーザーに対してHTTPステータスコード200(OK)とHTMLコンテンツを返します。

リクエストオブジェクトからデータを取り出す

ユーザーから送信されるHTTPリクエストには様々な情報が組み込まれています。
下記のようなデータにアクセスできます。
・ヘッダー
・GETデータやPOSTデータ

URLディスパッチャ

URLディスパッチャとは「あるURLに対してリクエストが送られた場合、レスポンスを返すビュー関数を指定する」ための設定です。

URLConf と呼ばれる設定ファイルに書かれます。URLConfは、一般的にプロジェクトまたはアプリケーションの urls.py です。

What is a URL?

URLは簡単に言えばWEB上のアドレスです。インターネットの全てのページはURLを持っています。
DjangoではURL_conf（URL設定）と呼ばれるものを使います。
これは、指定されたURLに合わせてDjangoがどのviewを返したらいいか判断する仕組みのことです。
それによって、これから作るアプリケーションが、URLを指定してアクセスしてきたユーザに、何を見せたらいいのかわかるのです。

Django のリクエスト処理

ユーザが Django で作られたサイト上のページをリクエストした時に、どの Python コードが実行されるかは以下のアルゴリズムで決定されます:

まず、Django は、どのモジュールをルート URLconf として使うか決定します。もともとは、この値は ROOT_URLCONF に設定されています。ただし、 HttpRequest オブジェクトに urlconf という属性が設定されていた場合( request processing で設定されます) 、その値を ROOT_URLCONF の代わりに使います。
Django は上記の Python モジュールをロードして、 urlpatterns という名前の変数を探します。この変数の値は Python のリストで、 django.conf.urls.patterns() が返すのと同じ形式です。
Django は URL パターンを順に調べて、リクエスト URL に最初にマッチしたところで止まります。
何らかの正規表現にマッチしたら、 Django はマッピングされているビューを import して呼び出します。ビューは単純な Python 関数です。ビュー関数の第一引数には HttpRequest が、それ以降の引数には正規表現でキャプチャした値が渡されます。
もし、正規表現が何にもマッチしなかったり、パターンマッチングプロセスの途中のどこかで例外が発生した場合、 Django は、適切なエラーハンドリングビューを呼び出します。エラーハンドリングを見てください。
凡例

URLconf の一例を示します:

from django.conf.urls import patterns, url, include

urlpatterns = patterns('',
(r'^articles/2003/$', 'news.views.special_case_2003'),
(r'^articles/(\d{4})/$', 'news.views.year_archive'),
(r'^articles/(\d{4})/(\d{2})/$', 'news.views.month_archive'),
(r'^articles/(\d{4})/(\d{2})/(\d+)/$', 'news.views.article_detail'),
)
注意:

URL 中の値を取り出すには、単に丸括弧で囲むだけです。
先頭のスラッシュは必要ありません。全ての URL に共通だからです。例えば、 ^/articles ではなく ^articles にします。
正規表現文字列のリテラルの前に 'r' があります。これは必須ではありませんが、付けた方がよいでしょう。 r は、”raw” 文字列、すなわち文字列中のいかなる文字もエスケープしないことを表します。 Dive Into Python’s explanation も参考にしてください。
例のリクエストを挙げて説明しましょう:

/articles/2005/03/ へのリクエストは 3 つめのエントリにマッチします。 Django は news.views.month_archive(request, '2005', '03') を呼び出します。
/articles/2005/3/ はどの UrL パターンにもマッチしません。リストの 3 つめのエントリでは月番号が 2 桁になるよう要求しているからです。
/articles/2003/ はリストの 2 番目ではなく、最初のパターンにマッチします。パターンは順番に調べられ、最初にテストにパスしたものが使われるからです。この法則を、特別扱いしたい URL の処理に使ってもかまいません。
/articles/2003 は URL がスラッシュで終わっていないので、どのパターンにもマッチしません。
/articles/2003/03/3/ は最後のパターンにマッチします。 Django は news.views.article_detail(request, '2003', '03', '3') を呼び出します。

URLConf設定を書く

http://qiita.com/juniskw/items/535d89677d9640f6734f
以下の記述が必要だがstartproject時に自動的に作られている。

setting.py

ROOT_URLCONF = 'mysite.urls'
urls.py内のURLConfも同様。まずはここにパターンを追加していく。

urls.py

from django.conf.urls import patterns, include, url # 追加

from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
# url(r’URLパターン’,’対応するビュー関数’)という書き方
url(r'^polls/$', 'polls.views.index'), # 追加
url(r'^polls/(?P\d+)/$', 'polls.views.detail'), # 追加
url(r'^polls/(?P\d+)/results/$', 'polls.views.results'), # 追加
url(r'^polls/(?P\d+)/vote/$', 'polls.views.vote'), # 追加
url(r'^admin/', include(admin.site.urls))
)