Python+Djangoを使ってみる（チュートリアルをやってみる：第６回）

Posted by on 2013年5月24日

久しぶりにDjangoに戻ってきました。
ブログのエントリーを見れば“Objective-Cを触っていた”ことはバレバレですね。

さて前回は、「IDEを設定する」という話でした。
今回は、Djangoのチュートリアルに戻って「Modelってやつをシバくぜ」ということをします。

Djangoのチュートリアルはここです。
サイトのページ内で「Creating models」を検索してください。
ここをやります。

１．今どういう状況か？

・mysiteという“Project”を作った
・mysite/settings.pyにデータベースとの接続情報を書いた

ディレクトリ構造は以下です。
mysite/ : プロジェクトを格納しているディレクトリ（名前は変更可）
　　manage.py : コマンドラインユーティリティ（django-admin.pyのラッパー）
　　mysite/ : Pythonパッケージ（結構重要っぽい）
　　　　__init__.py : Pythonパッケージであることを示す空ファイル（本質的にはパッケージを読み込む際に最初に実行するファイルっぽい）
　　　　settings.py : Djangoプロジェクトの設定ファイル
　　　　urls.py : DjangoプロジェクトのURL設定
　　　　wsgi.py : WSGI互換のWebサーバに対するエントリポイント

見た感じ「Webアプリケーションの外枠を決める役割」が並んでいるようですね。ビジネスロジックはどこに実装するのでしょう？画面は？という状態が“今”です。

２．Appを作る

こうしろと書いてあります。

$ python manage.py startapp polls

IDEとしてAptana Studio3を使っているのですが、「Terminal Window」にそのまま打ち込むとOKです。即座に「App Explorer」に反映されます。
おそらく、「Project Explorer」あたりで右クリックをしたら、なんらかの便利なことがありそうですが、そこら辺は良く分かりません（笑）。・・・何のためのIDEなんだろう？

こんなディレクトリが出来上がります。
polls/
　　__init__.py :これはアレですな。pollsをインポートした時に最初に実行されるファイルですな。
　　models.py :これが今回の主たる目的のModel定義ファイル
　　tests.py :これは名前からしてテスト用のファイル。
　　views.py :これはViewね！ではなく、MVCで言うとControllerだったような気がする。

ま、何かが足りないような気もするけど、画面とデータ定義があるので、「これで何かの処理が書けそう」という気にはなる。

３．今、何やった？

Projects vs. apps
What’s the difference between a project and an app? An app is a Web application that does something – e.g., a Weblog system, a database of public records or a simple poll app. A project is a collection of configuration and apps for a particular Web site. A project can contain multiple apps. An app can be in multiple projects.

Projectとapp（の違い）
Projectとappの違いは何か？appは-ブログや公開レコードのデータベースや単純な投票システムなどの-“何か”を実行するウェブアプリケーションである。projectは特定のウェブサイトのための設定ファイルとappsの集合体である。１つのprojectには複数のappを含むことができる。１つのappは複数のprojectに用いられることが可能だ。

つまり、「こんなWebサイトを作るぞ」というのはproject。そのサイトではあんなことやこんなことをするぞがapp。で、あるprojectで作ったappは他のprojectでも使うことができる。
・・・ということだと理解した。

っていうことは、“appは独立性が高くなければならない”に違いない。
「じゃ、mysiteの中に作っちゃダメじゃん」とか思ったのだが、たぶん、外出しにもできるのだろう。

確かに、こんなことが書いてある。

Your apps can live anywhere on your Python path. In this tutorial, we’ll create our poll app right next to your manage.py file so that it can be imported as its own top-level module, rather than a submodule of mysite.

appはPython path上のどこにでも存在できる。このチュートリアルでは（たまたま）manage.pyの隣にpoll appを作った。これはmysiteのサブモジュールではなく、mysiteのトップレベルモジュールとしてインポートされる。

・・・だったら“隣”に作らないで欲しかった。

それはさておき、とりあえず、「mysiteプロジェクトを作ったのだが、そいつは“投票機能”が必要なのでpoll appを含めなきゃね」ということをやったっぽい。

４．model定義を書く

polls/models.pyにこう書く。

from django.db import models

class Poll(models.Model):
    question = models.CharField(max_length=200)
    pub_date = models.DateTimeField('date published')

class Choice(models.Model):
    poll = models.ForeignKey(Poll)
    choice_text = models.CharField(max_length=200)
    votes = models.IntegerField(default=0)

・models.Modelを継承する
・models.CharFieldやmodels.DateTimeFieldやmodels.IntegerFieldで型定義ができる
・型定義の際に初期値などの属性を持てる
・models.ForeignKeyはリレーションに違いない
あたりが分かる。

５．modelを使えるようにする

定義を書いただけで動くわけはなく、「ここに書いたから処理しとけ」と指示を出さなきゃいけない。
そいつはmysite/settings.pyに書く。projectの設定ファイルに“含まれるapp”を書いておくというのは自然なこと。

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    'django.contrib.staticfiles',
    # Uncomment the next line to enable the admin:
    # 'django.contrib.admin',
    # Uncomment the next line to enable admin documentation:
    # 'django.contrib.admindocs',
    'polls',
)

６．締め

これをやる。

$ python manage.py syncdb

これをやると、「存在していないテーブル（＝新たに書き加えたmodel）を作る」ということをしてくれる。

今回はここまで。
modelの書き方の超基礎は分かった。しかし、実際の業務システムだともっと複雑になるし、もう少し構造化をしないとメンテナンスがしにくい。ここら辺は機会があれば記事にしたいと思う。

とりあえず、tutorial01は終了。

The following two tabs change content below.

ロゴスウェア

ロゴスウェア株式会社は、インターネットや情報技術を使って学習に革新的進化をもたらす製品を開発することを目標に、2001年7月に設立されたテクノロジー系ベンチャー企業です。
テクニック,

Comments are closed.