Django – テンプレートの場所

概要

  • Djangoのテンプレートファイルは、テンプレートディレクトリーやそのサブディレクトリーに置かれることを想定している
  • 複数場所に配置されたテンプレートディレクトリー以下が一括して探索される
  • 探索場所と順序はsettings.pyファイルのTEMPLATESの設定に従う
    • DIRSでは任意の場所・名前でテンプレートディレクトリーを追加できる
    • APP_DIRSTrueに設定されている場合、各アプリケーションディレクトリー下のtemplatesディレクトリーが探索される
  • 探索されたテンプレートを参照する場合、テンプレートディレクトリーからの相対パスで指定する
  • テンプレートディレクトリーを分散配置しても一括して検索されるため、各テンプレートディレクトリーに適切なサブディレクトリーを置いて、その下にテンプレートファイルを置くのが一般的

確認用プロジェクト

確認のためtemplatetestプロジェクトを準備し、app1app2の2つのアプリケーションを作成する。templatesディレクトリーとそのサブディレクトリーを以下のように作成し、4つの場所に即した内容のindex.htmlファイルを置く。

各場所のindex.htmlは、title要素/bodyp要素で以下を表示させるようにした。

  • App1/Under the app1 directory
  • App2/Under the app2 directory
  • Subirectory/Under the subdirectory
  • Base Directory/Under the base directory

そしてapp1のビューファイルで指定するテンプレート名のディレクトリー名を変更しながら、各場所のindex.htmlが読み込まれたかどうか確認する。

プロジェクトの完成後、template変数に設定した文字列を以下のように変更して、それぞれに対応したページが表示されるかどうかを確認する。

  • 'base/index.html'
  • 'subdirectory/index.html'
  • 'app1/index.html'
  • 'app2/index.html'

TEMPLATESの初期設定

初期状態でのTEMPLATESは以下の通り。

このうちテンプレートの探索場所は'DIRS''APP_DIRS'で設定される。

なおディレクトリーの探索場所が設定されていれば、そのサブディレクトリー下も再帰的に探索される。

DIRSでの設定

プロジェクトディレクトリー直下

'DIRS'にはプロジェクト内任意の場所の、任意の名前のディレクトリーを設定できる。たとえばプロジェクトディレクトリー直下に置いたtemplatesを探索させるなら以下のように記述する。

または

後者の場合、settings.pyではimport osがないので追加が必要。

この設定により、'templatetest/templates/base/index.html'のレンダリングが可能になる。

サブディレクトリー下

プロジェクトの設定ファイル群があるサブディレクトリー下(この場合configディレクトリー)にあるディレクトリーを探索させるときは以下のように相対パスで設定する。

または

この場合もsettings.pyimport osが必要。

この設定により、templatetest/config/subdirectory/templates/index.htmlのレンダリングが可能になる。

APP_DIRSの設定

また、'APP_DIRS'Trueに設定されている場合は、各アプリケーションディレクトリー下にあるtemplatesディレクトリーが探索される。

デフォルトでTrueがセットされているので、アプリケーションディレクトリー下にtempratesディレクトリーがあれば全て探索される。

この例の場合、app1/templatesapp2/templatesは、デフォルトの設定)のままでそれぞれのサブディレクトリーも含めて探索される。

この結果templatetest/app1/templates/app1/index.htmltemplatetest/app2/templates/app2/index.htmlのレンダリングが可能になる。

全てを探索させるTEMPLATESの設定

これまでの4つの場所のすべてを探索対象とするには、settings.pyTEMPLATESを以下のように設定する。

この結果、以下の4つが探索可能になる。

  • templatetest/templates/base/index.html
  • templatetest/config/templates/subdirectory/index.html
  • templatetest/app1/templates/app1/index.html
  • templatetest/app2/templates/app2/index.html

templatesのサブディレクトリー

特にアプリケーションディレクトリー下にテンプレートを置く場合に、(index.htmlのように)同じ名前のファイルが重複しないよう、サブディレクトリーを設けるのが一般的。

通常、サブディレクトリー名はアプリケーションディレクトリー名と同じとする。冗長だが重複が防止され、可読性も保たれる。

 

 

Django – Hello! – 単純なアプリケーション

概要

特定のURLにアクセスするとブラウザーに”Hello!”とだけ表示させるプロジェクトを作成する。要点は以下の通り。

  • Djangoのプロジェクトは複数のアプリケーションを含むことができる
  • アプリケーション作成はmanage.pystartappオプションで実行
  • リクエストに対応した処理を行うview関数をviews.pyに定義
  • 特定のURLへのアクセスが対応するview関数にルーティングされるよう、urls.pyに設定

仕様

動作は以下の通り。

  • URLにhttp://localhost:8000/helloを指定してリクエスト
  • 文字列"Hello!"を返す(ブラウザーに表示される)

構造は以下の通り。

  • Hello表示のアプリケーションをhelloとする
  • リクエストに対応するview関数をsay_hello()とする
  • say_hello()はリクエストに対して文字列"Hello!"をレスポンスで返す

プロジェクトのスタート

まずgreetingsという名前でディレクトリーを作成し、そのディレクトリー下にプロジェクト作成。ここではサブディレクトリー名をconfigとしている。

プロジェクトの構成は以下の通り。

settings.py編集後にサーバーを起動してDjangoのwelcomeページが表示されることを確認しておく。

ここでのsettings.pyの編集内容は以下の通り。

  • ALLOWED_HOSTSへの追加
  • DATABASESのコメントアウト
  • 言語とタイムゾーンの設定

サーバー起動はVagrantのプライベート環境下なので以下の通り。

ブラウザーからのアクセスはhttp://localhost:8000で。

アプリケーションの作成

アプリケーション作成は、プロジェクトディレクトリー直下(manage.pyのある場所)で以下を実行。

ここでは、ブラウザーに”Hello!”を表示するためのhelloアプリケーションを作成する。greetingsディレクトリー下で以下を実行。

ディレクトリー構成は以下のようになる。新たにhelloディレクトリーが追加されている。

settings.pyにアプリケーションを追加

プロジェクトでhelloアプリケーションを認識するため、settings.pyINSTALLED_APPSにアプリケーション名'hello'を追加。

viewの作成~views.py

リクエストに対応した処理を、helloアプリケーションディレクトリー内のviews.pyファイルに記述。

  • 単純にHTTPレスポンスで文字列を返すため、HttpResponseをインポート
  • view関数としてsay_hello()を定義し、文字列を返すよう記述

ルーティング~urls.py

想定しているURLに対して定義したview関数が呼ばれるようにルーティング。プロジェクトサブディレクトリーのurls.pyファイルに記述を追加する。

  • say_hello()を使うためインポートが必要
  • urlpatterns/helloからsay_hello()へのルーティングを定義

ブラウザーから接続

以下のURLでブラウザーに”Hello!”と表示される。

なお、これ以降localhost:8000のルートに接続すると404エラーとなる。

ルーティングを記述したurls.pyにホストのルートへのルーティングを追加すると、http://localhost:8000のURLに対しても”Hello!”が表示されるようになる。

 

Django – プロジェクトの作成

概要

Djangoのプロジェクト作成はdjango-admin startprojectで行う。新規にプロジェクトディレクトリーを作成する方法と、既存のディレクトリーに作成する方法がある。

新規にプロジェクトディレクトリーを作成する方法では、プロジェクト名のみを指定する。

この場合プロジェクト名と同じディレクトリーが作成され、その下に同じ名前のサブディレクトリーとmanage.pyファイルが作成される。

既存のディレクトリーに作成する方法では、第1引数にサブディレクトリー、第2引数に既存のプロジェクトディレクトリーを指定する。

この場合、既存のプロジェクトディレクトリーの下にサブディレクトリーとmanage.pyファイルが作成される。

何れの場合もサブディレクトリーの内容は同じで、プロジェクト全体に関する設定ファイルなどが作成される。

manage.pyはコマンドラインで管理レベルの操作を行うためのファイル。

プロジェクト名だけを指定する場合

プロジェクト名だけを指定した場合は、その名前でディレクトリーが作成され、その下に同じ名前のサブディレクトリーとmanage.pyファイルが作成される。

もし同じ名前のディレクトリーが既に存在していた場合はエラーとなる。

以下は新規作成されたプロジェクトディレクトリーの内容

サブディレクトリーの下には、プロジェクト全体に関する設定ファイルが作成される。たとえばsettings.pyファイルは、プロジェクトの言語やタイムゾーン、データベースなどに関する設定を記述する。

既存のディレクトリーに作成する場合

空のプロジェクトディレクトリーを作成し、第1引数にサブディレクトリー、第2引数にプロジェクトディレクトリーを指定して実行する。

もし指定したプロジェクトディレクトリーが存在しない場合はエラーになる。

なお、以後の作業をプロジェクトディレクトリー内で行うことを想定して以下のように実行してもよい。

この場合のディレクトリー構成は以下のようになる。

 

 

Django – 初期設定とサーバー起動

概要

主な留意点は以下の通り。

  • DjangoのデフォルトDBMSはSQLite
  • 言語・タイムゾーン・DB設定などはsettings.pyで記述(Laravelの.envに相当)
  • Vagrantなどの仮想環境の場合はサーバー起動のIPに注意
    →ゲスト側でALLOW_HOSTSの設定も必要

当初に発生したエラーと対応についてはこちら

データベースクライアントのインストール

DjangoのデフォルトではSQLiteとなっている。SQLiteの場合は一定以上のバージョンが要求される模様。

他のDBMSを使う場合、クライアントをインストールしておく必要がある。以下はMySQLを使う場合にmysqlclientをインストールした例。

settings.py~各種設定

言語とタイムゾーン

言語を日本語に、タイムゾーンを日本のものに設定。

データベース設定

デフォルトのSQLiteではなくMySQLを使う例

ホスト許可

Vagrantなど仮想環境のプライベートネットワークで接続する場合、ここに設定が必要。

Vagrantの場合

Vagrantfileの設定

ポートマッピング設定。プライベートネットワークはデフォルト。

ゲスト側IP確認

ゲスト側の仮想環境でサーバーを起動する場合のIPを確認。ホスト側では127.0.0.1にセットされている。

開発用Webサーバー起動

ifconfigで確認したゲスト側のIPでサーバーを起動する。

ブラウザーで接続

ホスト側のブラウザーで、http://localhost:8000かhttp://127.0.0.1:8000で接続。

 

CwntOS7 – Djangoのインストール

概要

Vagrant上のCentOS7にDjangoをインストール。

virtualenvの仮想環境でインストールした場合、元のシステムには影響を与えない。

手順

Python3インストール済みの環境でDjangoをインストール。特に問題なくインストール完了。

バージョンチェック。

Python3からもチェック。

 

Vagrant – CentOS7 – Python3 – virtualenv

概要

Vagrant上のCentOS7で、virtualenvをインストールしてPython3の仮想環境をつくった手順の記録。

  • pipvirtualenvwrapperをインストールする
  • sudoでインストールすると警告が出てグローバルにインストールされる

許可がなくインストールできない

pip3virtualenvwrapperをインストールしようとしたところ、許可がないとエラーになった。

ディレクトリーに書き込み権限がない。

sudoで警告が出るがインストール

以下のような警告が出るが、インストールは実行される。

WARNING: Running pip install with root privileges is generally not a good idea. Try `pip3 install –user` instead.

グローバルインストールするのに対して、--userオプションでユーザーディレクトリーへのインストールを促している。

確認

virtualenvのバージョン確認。

仮想環境構築の確認。

ディレクトリー確認。

仮想環境の有効化。

仮想環境の無効化と削除。

操作

基本操作

ディレクトリーを作成して仮想環境を作成。絶対パスでなければ現在のディレクトリー下に作成される。

$ virtualenv directory

仮想環境の有効化。

$ source directory/bin/activate
または
$ . directory/bin/activate

仮想環境の無効化。

(directory) $ deactivate

仮想環境の削除

$ rm -rf directory

応用

Pythonのバージョン指定

$ virtualenv -p python3.6 directory

システムのPythonパッケージ群を仮想環境からも参照

$ virtualenv --system-site-packages directory

virtualenvwrapperの利用

.bashrcの編集と再読み込み

virtualenvだけでも基本的な操作はできるが、virtualenvwrapperを利用すると便利なコマンドが使えるようになる。そのために~/.bashrcに以下の3行を加える。

.bashrcを実行して反映させる。

1行目のWORKON_HOMEで指定したディレクトリーが作成され、ここに仮想環境ごとのディレクトリーが作成される。

2行目を設定しないと以下のエラーが出る。エラーが出てもvirtualenvwrapperは利用できたが入れておく。

3行目はvirtualenvwrapper.shを実行させる。

.bashrcの実行後、~/.virtualenvsディレクトリーと必要なファイルが作成される。

確認

仮想環境を作ってみる。

python3の場所が仮想環境内になっていて、元のシステムの場所とは違う。

もう一つ仮想環境を作って、workonコマンドで見てみる。lsvirtualenvコマンドもあるが、workonコマンドとの違いがよくわからない。

仮想環境にモジュールをインストールしてもシステムに影響がないことを確認する。まずシステムにはNumpyモジュールがインストールされていないことを確認。

仮想環境でもNumpyはインストールされていない。

Python3をexit()で抜けて、仮想環境のコマンドラインでNumpyをインストール。

Python3でNumpyが使えるようになった。

Python3をexit()で抜けて、仮想環境からも抜ける。元の環境ではNumpyはインストールされていないことがわかる。

virtualenvwrapperのコマンド

仮想環境の作成・有効化。WORKON_HOMEで設定したディレクトリーに作成される。

$ mkvirtualenv envname

仮想環境の無効化。

(envname) $ deactivate

仮想環境の一覧。

$ workon
または
$ lsvirtyalenv -b/-l

仮想環境の有効化。

$ workon envname

仮想環境ディレクトリーへの移動。

$ cdvirtualenv envname

仮想環境の削除。

$ rmvirtualenvname envname

 

Vagrant – CentOS7 – Python3インストール

概要

Vagrant上のCentOS7にPython3をインストールした記録。

要点は以下の通り。

  • IUSのリポジトリーでインストール
  • --enablerepo=iusが必要

バージョン確認

まずPythonのバージョンを確認する。

一応Python2の動作確認。

Python3はインストールされていない。

IUSのリポジトリー追加

リポジトリー追加ができない。

リポジトリーは作成できている。

GitをインストールしたときにIUSのリポジトリーをインストールしていたのを忘れていた。

Python3がインストールできない

Python3.6をインストールしようとするができない。

/etc/yum.repos.d/ius.repoの設定でenabled = 0になっているため。Gitのインストールの時に書き換えているが、毎回元に戻るのか?

オプション設定でインストール成功

設定ファイルを書き換えてもよいが、yum実行時のオプションで--enablerepo=iusを追加して成功。

確認

バージョン確認。

動作確認。

Python2ではない。

python3の場所。

pipのバージョン確認。

 

PHP – Pythonのzip()

Pythonのzip()関数は、複数のコレクションの要素をパラレルに取り出すことができる。

PHPでは、array_map()関数を使って同様のことができる。

以下はコードで確認した例。

これをforeachに入れて各要素を配列で受け取れば、複数配列の要素をパラレルに得ることができる。

 

さくらサーバー – Laravel~デプロイ

概要

ローカルで開発したLaravelのプロジェクトを、さくらのレンタルサーバーにデプロイした時の記録。

  • ローカルで
    • CentOS7~Laravel~MySQLで開発
    • 必要に応じてデータベースのダンプファイルも含める
    • GitHubのリポジトリーに登録
  • さくらサーバーにssh接続
    • 秘密鍵と公開鍵をさくらサーバーにコピー
    • GitHubのリポジトリーをclone
    • 必要に応じてデータベースのダンプファイルから復帰
    • Laravelのpublicディレクトリーのシンボリックリンクを公開ディレクトリーに作成

躓いたのは以下の点

  • ssh鍵ファイルのパーミッション設定
  • login/registerのパス設定

Laravelを直接さくらサーバー上でインストールする手順はこちら

ローカルでの開発

プロジェクトの開発

通常の方法によって、ローカル環境でLaravelプロジェクトを開発。このとき、さくらのサーバー上で利用可能なPHP/Laravel/MySQLのバージョンを確認しておく。

データベースのダンプ

開発中にデータベースの実データを扱っている場合は、データベースの内容をダンプファイルに出力しておく

今回はリポジトリーのディレクトリーにダンプファイルを保存して、GitHub経由で共有した。

GitHubへのpush

ローカルの開発結果をコミットしてGitHubへpush。以下の手順によった。

  1. git add -f .venderディレクトリーなども含めてステージング
  2. git commit -mでコミット
  3. git pushでGitHubのリポジトリーに反映

ローカルでの状況は以下のとおり。

  • プロジェクトの配置→.../laravel/PROJECT/
  • ローカルサーバー→PROJECT/下でサーバーを起動
  • ローカルでのアクセス→localhost:3000/
  • GitHubのリポジトリー→laravelディレクトリー以下

さくらサーバーでのデプロイ

ssh接続の準備

GitHubとSSHでやり取りする準備。

  •  秘密鍵(id_rsa)と公開鍵(id_rsa.pub)をさくらサーバーにアップロード
    • アップロード先は~/.ssh/ディレクトリー
    • .ssh/ディレクトリは既に存在していて、パーミッションは700
  • アップロードした2つの鍵ファイルのパーミッションを600に変更する必要がある

ssh鍵でのエラー

当初、鍵ファイルのパーミッションが他者から読み取り可能のままになっていて接続できなかった。

2つの鍵のパーミッションを600に変更して解決。

プロジェクトの配置計画

さくらサーバーでの配置計画は以下のようにした。

  • プロジェクト本体は公開領域以外に置く
  • 公開領域にプロジェクトのpublicディレクトリーのシンボリックリンクを置く
  • シンボリックリンクの名前をプロジェクト名にする

これによって、”サイト名/プロジェクト名“というURLをアプリケーションのメインページとすることができる。

プロジェクトのダウンロード

GitHubのリポジトリーをさくらサーバーのユーザーホームディレクトリー下でclone。

故人開発であり、git pull/pushにするとサーバー側での.envの編集などの本質でない操作などが反映されてしまうので、ローカル側で編集したプロジェクトをさくらサーバー上でcloneするのがよいと考えた。

.envファイルの編集

さくら側のMySQLに接続するため、.envファイルの以下を変更。

  • MYSQL_HOSTはさくらのMySQLホスト名
    • mysql**.ユーザー名.sakura.ne.jpなど
  • DB_NAMEはさくら上でのDB名
    • ユーザー名_任意のDB名など
  • USER/PASSはMySQLに接続するためのユーザー名とパスワード

publicディレクトリーのシンボリックリンク

非公開に置いたプロジェクトのうち、公開対象のpublicディレクトリーのシンボリックリンクを公開領域(~/www)に作成する。リンク名はプロジェクト名と同じにした。

ログイン・サインアップできない

Laravelでの症状

当初プロジェクトをさくらサーバーに配置したとき、以下のような状況になった。

  • 非認証時のメインページや説明ページなどは表示・遷移できる
  • ログインやサインアップのフォームページも表示される
  • ログインページで入力後にボタンを押すと、WordPressのログイン画面に遷移してしまう
  • サインアップページで入力後にボタンを押すとWordPressの「ページが見つかりませんでした」表示

元々ドメイン直下ではWordPressが実行されるようになっていて、サブディレクトリーでLaravelを動かそうとしてこのような状況になった。

URL指定による同じ状況の再現

LoginController/RegisterControllerredirectToを変えたり、ルーティングファイルやindex.phpを触ったりしてみたが、状況は変わらず。その中で、以下のことに気づく。

  • URLで直接http://DOMAIN.com/loginを指定すると、WordPressのログイン画面に遷移する
  • URLで直接http://DOMAIN.com/registerを指定すると、WordPressの「ページが見つかりませんでした」表示

原因特定

Laravelではいずれもボタンを押した後に上と同じ状況になることに気づき、login.blade.phpregister.blade.phpを見てみると、POSTを発しているform要素のaction"/login""/register"を直に書いていた。

これらをルート名で"{{ route('login') }}""{{  route('register') }}"に変更したところ、正常にログインとサインアップができるようになった。これらのルート名は、Auth::routes()で設定自動的に設定されるので、artisanで確認。

考えてみれば至極当然の挙動で、ローカルと本番で配置形態が変わる場合に備えて徹底的にroute()を使うのがよさそう。

 

さくらサーバー – Laravel~インストール

概要

さくらレンタルサーバーのスタンダードプランを利用していて、そこにLaravelをインストールしてみた記録。以下の2つの方法を試してみた。

  • composerをドキュメントルートに配置し、ドキュメントルート下にプロジェクトを作成
  • composerをドキュメントルートと別の場所に配置し、ドキュメントルート下で公開

ローカルで開発したプロジェクトをデプロイする手順はこちら

ドキュメントルートへのインストール

composerのインストール

ssh接続後~/www(ドキュメントルート)に移動し、composer.pharをダウンロード。

インストール確認。

プロジェクト作成

~/wwwディレクトリーでテスト用のプロジェクトを作成。

動作確認

welcomeページ

ブラウザーでURLを指定。

結果は以下のエラー。

Forbidden
You don’t have permission to access this resource.

 

URLを以下のように指定して、welcomeページが無事表示される。ドキュメントルート下にプロジェクトを配置すると、publicディレクトリー内が公開対象になる。

ルーティング

以下のルーティングで'Hello'が表示される。

コントローラー

TestControllerコントローラーを作成してアクションを定義し、その中で文字列を渡す。

ルーティングを以下のように変更。

これでブラウザーに'Hello!'と表示される。

ビュー

resource/viewsディレクトリーに以下のビューファイルtest.blade.phpを作成。

TestControllerを以下のように修正。

これでブラウザーにアクセスすると、タブのタイトルが'Laravel Test'となり、h1要素のフォントで'Hello from blade!'と表示される。

別ディレクトリーへのインストール

composerのインストール

ドキュメントルート下にプロジェクトを配置するのは気持ち悪いので、別に配置する。ここではユーザーホーム下のディレクトリーに配置してみる。ライブラリーを加えていないので、インストールはcomposer.pharを移動して配置するのみ。

まずcomposer_testディレクトリーを作ってその下にcomposer.pharを移動。また、先にドキュメントルートに作ったプロジェクトを削除しておく。

移動先でcomposerの動作確認。

プロジェクトの作成

composer_testディレクトリー下に先と同じ手順でプロジェクトを作成。

公開ディレクトリーへのシンボリックリンク

公開ディレクトリー以外に配置したプロジェクトは、クライアントからは認識されない。そこでプロジェクトのpublicディレクトリーのシンボリックリンクをドキュメントルート下に作成する。

ここではシンボリックリンク名をプロジェクト名と同じ名前にして、~/wwwディレクトリー下に作成。

この状態で以下のURLを指定するとwelcomeページが表示される。

コントローラー・ビュー

新しいプロジェクトでTestControllerコントローラーを作成。

ビューを呼び出すアクションを定義。

ルーティングを定義。

resources/views/ディレクトリーにtest.blade.phpファイルを以下の内容で作成。

これでブラウザーにアクセスすると、タブのタイトルが'Laravel Test'となり、h1要素のフォントで'Hello from blade!'と表示される。

Laravelのバージョン指定

composerでプロジェクトを作成するときにLaravelのバージョン指定が可能だが、さくらサーバーでワイルドカードを使うとうまくいかない。

以下のようにワイルドカードを指定しない方法だと、無事にプロジェクトが作成される。

バージョン確認。

プロジェクトの設定

タイムゾーンとロケールをconfig/app.phpファイルで設定。

データベースはさくらサーバーの設定に従って、.envファイルで設定。DB_HOSTはmysql5.7アップグレード後の場合、phpMyAdminなどで使われるサーバー名。