差分

このページの2つのバージョン間の差分を表示します。

--- メモ:django [2019/05/29 14:09] – [テスト用の内部サーバ起動] Wiki Editor
+++ メモ:django [2019/06/05 17:30] (現在) – [app01/app01/urls.py] Wiki Editor
@@ 行 42: / 行 42: @@
 コマンドでの待ち受けIPを指定するとローカルホストからのみ接続できる。ここでは別ホスト上に開発環境があるので、接続されているインターフェースにバインドする。0を指定すればすべてのインターフェイスにバインド。
-起動コマンドでIPアドレスにアサインすることと、設定ファイルの接続許可が両方正しく設定されて、初めて外部から接続できる。うまく起動できれば、http://{IP Address}:8000/でテストサーバに接続され、ロケット打ち上げが表示される。
+起動コマンドでIPアドレスにアサインすることと、設定ファイルの接続許可が両方正しく設定されて、初めて外部から接続できる。うまく起動できれば、http://[IP Address]:8000/でテストサーバに接続され、ロケット打ち上げが表示される。
+===== その他の基本設定 =====
+app01/settings.pyの基本設定
+言語やタイムゾーンを設定
+  LANGUAGE_CODE = 'ja'
+  TIME_ZONE = 'Japan'
 ===== アプリケーションの作成 =====
@@ 行 55: / 行 62: @@
+===== Viewの作成 =====
+Viewはアプリケーションのロジック、処理を行う中心的な部分。データの加工やテンプレートの呼び出しなど、様々な処理を担当する。
+==== app01/report/views.py ====
+viewの本体。とりあえず単純に文字を表示するだけ。
+  from django.shortcuts import render
+  from django.http import HttpResponse
+  def index(request):
+      return HttpResponse("Hello, Django.")
+==== app01/report/urls.py ====
+URLのディスパッチ設定。アプリケーションレベルのURLはここでディスパッチする。このファイルは、プロジェクトレベルのURLディスパッチにインクルードして使う。アプリケーション作成時には自動作成されない。
+urlpatternsにURLとViewの対応を設定する。ここでは「%%''%%」でルートディレクトリへのアクセスをviews.pyのindex関数と対応づける。
+  from django.urls import path
+  from . import views
+  urlpatterns = [
+      path('', views.index, name='index'),
+  ]
+==== app01/app01/urls.py ====
+プロジェクトレベルのURLディスパッチ
+include関数を読み込んで、アプリケーションレベルのURLディスパッチ設定ファイルを読み込むように設定する。
+ここでは/report/以下のURLはreport/urls.pyを読み込んで処理する。
+  from django.contrib import admin
+  from django.urls import path, include
+  urlpatterns = [
+      path('report/', include('report.urls')),
+      path('admin/', admin.site.urls),
+  ]
+以上を設定すると、%%http://[IP Address]:8000/report/%%で「Hello, Django.」が表示される。
+===== Model =====
+データベースからデータを呼び出したり保存したりする。直接クエリを発行するのではなく、オブジェクトを介して操作。
+==== データベース ====
+開発途中は取りあえずSQLiteを利用する。本番環境ではPostgreSQLなりMySQLに切り替える。データベースの定義はDjangoが自動的に生成してくれるので、バックエンドはあまり意識する必要はない。とりあえず、設定ファイルだけ確認しておく。
+app01/app01/settings.py
+  DATABASES = {
+      'default': {
+          'ENGINE': 'django.db.backends.sqlite3',
+          'NAME': os.path.join(BASE_DIR, 'db.sqlite3'),
+      }
+  }
+標準ではSQLiteが使われる。
+Djangoのフレームワークとして必要なテーブルを作成し準備を整える。
+  $ python manage.py migrate
+設定ファイルを参照し、必要なテーブルをデータベースに生成する。
+初期に必要なテーブルは、settings.pyのINSTALLED_APPに列挙されているフレームワークの組み込みアプリケーションを中心に生成される。自分で作成したアプリケーションでモデルを作成すると、migrateによって必要なテーブルが作成される。
+==== Modelの作成 ====
+モデルの定義を作成する。
+app01/report/models.py
+  from django.db import models
+  class Choice(models.Model):
+      categ_code = models.CharField(max_length=10)
+      categ = models.CharField(max_length=200)
+      hs_code = models.CharField(max_length=10)
+      hs = models.CharField(max_length=200)
+      def __str__(self):
+          return self.categ + self.hs
+  class Report:
+      hs_code = models.ForeignKey(Choice, on_delete=models.PROTECT)
+      report_field01 = models.CharField(max_length=1000)
+      report_field02 = models.CharField(max_length=1000)
+      report_field03 = models.CharField(max_length=1000)
+      def __str__(self):
+          return str(hs_code) + self.report_field01
+つのテーブルは1つのクラスとして定義される。クラスのサブクラスや変数で様々な挙動が設定できる。最も基本的な設定として、クラスの変数がデータベースに対応する。変数にデータの型や外部キーなどを設定していく。
+クラス内の「__str__」関数は、モデルのオブジェクト表現となる。管理画面で一覧表示するときなどに使われる文字列を定義できる。
+==== Modelをフレームワークに認識させる ====
+migrationでテーブルを管理するために、フレームワークに作成したアプリケーションを認識させる必要がある。先に示したsettings.pyのINSTALLED_APPに列挙すればよい。
+app01/app01/settings.py
+  INSTALLED_APPS = [
+      'report.apps.ReportConfig',
+      'django.contrib.admin',
+      'django.contrib.auth',
+      'django.contrib.contenttypes',
+      'django.contrib.sessions',
+      'django.contrib.messages',
+      'django.contrib.staticfiles',
+  ]
+ここで記述するのはアプリケーションのクラス名となる。プロジェクトディレクトリからクラスをたどって記述する。ここでは、reportアプリケーションのapps.pyファイルに定義されているReportConfigクラスとなる。このクラスはstartappでアプリケーションを作成した際に自動的に生成される。
+===== データベースへの反映 =====
+定義したモデルに対応してバックエンドのデータベースを作成する。
+  $ python manage.py makemigrations report
+makemigrationsコマンドでモデルの変更を検出し、migrationの定義ファイルを生成する。ポイントは、この時点でデータベースへの変更は一切行われていない点である。migrationの定義内容は、report/migrations/xxxx.pyに生成される。
+migrationで実行される具体的なSQLを確認する。
+  $ python manage.py sqlmigrate report 0001
+最後の引数はmigrationの定義ファイルのファイル名に対応する。何度もモデルを変更すると、そのたびにmigrationが生成され、履歴が残るようになっているようだ。対象となるファイルのmigration内容を確認するために、ファイルの番号を指定する。
+必要なテールが意図通りに作成されることが確認できれば、再度migrationを行いバックエンドのデータベースに反映させる。
+  $ python manage.py migrate