Django入門: アプリのインストール ～ 簡単な一行掲示板アプリを作る その3【Windows10】
- 作成日: 2020-10-16
- 更新日: 2023-12-26
- カテゴリ: Django
はじめに
前回までにDjangoでlinebbsというプロジェクトを作成し、そのプロジェクト内にbbsというアプリを作るところまでやりました。
今回は作成したアプリをプロジェクトにインストールするところからやってみたいと思います。
また、使用するOSはWindows10で、シェルはコマンドプロンプトを使います。
venv\Scripts\activateでコマンドプロンプトをアクティベートしている前提で話を進めます。
この辺の話がよくわからない人は本シリーズの第1回目をご覧ください。
アプリのインストール
Djangoでプロジェクトとアプリを作成したら、次にやることはアプリのインストールです。
python manage.py startappでアプリを作成するだけではDjangoはアプリを認識してくれません。
Djangoに作成したアプリを認識させる作業は手作業で行います。
manage.pyのあるフォルダに移動します。
> dir
bbs
db.sqlite3
linebbs
manage.py
linebbsというのがプロジェクトの中核フォルダです。
この中に移動して中を見てみます。
> cd linebbs
> dir
asgi.py # 非同期サーバーゲートウェイインターフェイス
settings.py # プロジェクトの設定
urls.py # 最初に解決されるルート
wsgi.py # 普通のサーバーゲートウェイインターフェイス
__init__.py # このフォルダをモジュールとして認識させるためのファイル
__pycache__ # Pythonが自動で作成したキャッシュ
色々入ってますが、この中のsettings.pyを弄ります。
エディターでsettings.pyを開くと、何やらわけのわからない文字列がたくさん並んでいると思います。
肝心のアプリのインストールで参照する情報は↓の部分だけです。
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
]
INSTALLED_APPSというリストが定義されています。
このリストにはDjangoに認識させたいアプリの名前を入れます。
既に入っているのは、Djangoにデフォルトでインストールされているアプリです。
あとはこのリストを編集して、↓のようにbbsという文字列を追加します。
INSTALLED_APPS = [
'django.contrib.admin',
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.messages',
'django.contrib.staticfiles',
'bbs', # <- ここに作成したアプリの名前を追加
]
このインストールするアプリの順番は、アプリによっては重要になってきます。
つまり、このリスト内のアプリ名の順番によってアプリの挙動が変わったりします。
特に必要が無ければ、自分のアプリはリストの末尾に追加するようにします。
これでアプリのインストールが完了しました。簡単ですね。
アプリのインストールに問題が無いか以下のコマンドでチェックしてみましょう。
> python manage.py check
python manage.py checkはプロジェクト全体に潜在的な問題がないかチェックするコマンドです。
特に問題が無ければ↓のように表示されます。
System check identified no issues (0 silenced).
たとえばINSTALLED_APPSに追加したアプリ名が間違っている場合は↓のようなエラーになります。
↓の例ではINSTALLED_APPSにhigeという存在しないアプリ名を追加しました。
> python manage.py check
...
ModuleNotFoundError: No module named 'hige'
higeというアプリは存在しないので、↑のようにModuleNotFoundErrorが画面に出力されます。
このようにpython manage.py checkはプロジェクト、アプリに問題が無いかチェックしてくれます。
なにか作業をやったらこのコマンドでプロジェクトの状態をチェックするクセを作っておくといいでしょう。
DjangoのMVT
アプリのインストールが完了したので、これからアプリの開発に移っていくわけですが、その前にDjangoの持つアーキテクチャの話をさせてください。
DjangoではMVTというアーキテクチャを採用しています。
これは
- Model
- View
- Template
の頭文字（M, V, T）です。
モデル（Model）, ビュー（View）, テンプレート（Template）はそれぞれ役割を持ち、それらが組み合わさってアプリ全体が動作するようになっています。
モデルはデータベースにデータを保存したり、逆でデータを取ってくる役割を持っています。
これはmodels.pyやmodels\内にモデルが保存され、ビュー（View）から使用されます。
ビューはルート情報とモデル、テンプレートを連結させる役割を持っています。
これはviews.pyやviews\内にビューが定義され、ルートから使用されます。
テンプレートはビューから与えられたデータを元にHTMLを描画する役割を持っています。
これはtemplates以下にHTMLファイルとして作成されます。
さらにこのアーキテクチャに加えて、ルート情報というのも大事になってきます。
ルート情報というのはurls.pyに定義される情報で、「リクエストされたパスに対してどのビューを呼ぶか？」という情報が記述されています。
DjangoがHTMLを表示するまでに起こること
DjangoはブラウザにHTMLを表示するわけですが、その過程はこうです。
まずDjangoはブラウザのリクエストしたパスに応じて、ルート情報（urls.py）を参照します。
そしてこのルート情報から、パスに応じたビューを呼び出します。
ビューは必要によってモデルを操作してDBに変更を加えたりデータを取得したりして、テンプレートを描画します。
テンプレートはビューから与えられたデータを元にHTMLを描画します。
Django（正確にはWebサーバー）はその描画されたデータをレスポンスとしてブラウザに返します。
こうしてめでたくユーザーのブラウザには我々が作成したアプリのページが表示されるわけです。
実際にはルート情報の参照前にsettings.pyを参照してアプリの初期化をしたりとか、Djangoは我々に隠れていろいろやってくれてるわけですが、そういった細かいことを考えない場合のおおまかな流れは↑のような流れです。
しかしDjangoがsettings.pyを参照しているという情報は頭の片隅に置いておいてください。
つまり、settings.pyに記述ミスがあった場合、Djangoはゲーゲーとエラーを吐くということです。
ブラウザにレスポンスを返すのはWebサーバー、開発中はDjangoの開発用Webサーバーの仕事ですが、これも特に意識しなくても問題ないようにDjangoは作られています。
しかしプロジェクトをレンタルサーバーにデプロイする時、このWebサーバーというのは途端に顔を出してきますので、これもどこか頭の片隅に置いておくと良いでしょう。
ちなみにこのチュートリアルではレンタルサーバーにプロジェクトをデプロイするところはやりません。
おわりに
今回はアプリをインストールし、MVTについて解説しました。
次回から実際にDjangoのMVTを使ってアプリを開発していきたいと思います。
🦝 < 来週のDjangoはM・V・Tの三本立て！