Django:Templateで意図したものと別のファイルが読み込まれる時の原因と対策

Django:Templateで意図したものと別のファイルが読み込まれる時の原因と対策

Django:Templateで意図したものと別のファイルが読み込まれる時の原因と対策

この場合、多くがTemplateディレクトリに置いたファイルの読まれ方の理解不足が原因です。
そして、多くの場合『同一プロジェクトに複数アプリ』という構成で構築している事でしょう。
私もこの【Templateディレクトリ】のファイルの扱いには悩まされました。

Templateディレクトリは『どのアプリ』からも全てのTemplateディレクトリが統一された姿で見える。

以降は具体的な例で解説していきます。

Templateが意図した通りに動かなかった事ありませんか?

私が経験したのはこんな動作です。

  1. 複数アプリを起動し「それぞれのサイドナビ」を「それぞれのTemplate直下にsidenav.htmlとして保存」したのにアプリごとにサイドナビの切り替えができない。
  2. TemplateSyntaxError が出たけど読み込もうとしたページで利用していないはずの 引数に対してエラーを指摘された。

この画像は1の例です。実際に私が作成している「自分専用アプリ」のサイドメニュー画面になります。この例ではModeChange内にあるリストをクリックすると其々のページにJUMPし、専用メニューが出てくるようにしています。

店舗分析では店舗分析専用の遷移、パーソナルCMSではシステム屋のとしての遷移といったようにアプリ毎にメニュー構成を変えたいという要望は多くあると思います。
ちなみに、Cloverは娘の自由研究用のDBです。私のグラフ作成練習にちょうどいいのでパーソナルシステムに組み込んでしまいました。

こういったアプリ毎のサイドメニューの切り替えをしたかったのですが、何故か意図した通りに動いてくれなかったんですよね。

Templateディレクトリは全てのアプリで統合管理されている

私の経験した上の項目1-2ですが根本原因はTemplateディレクトリの理解不足でした。

意図したとおりに動くTemplateディレクトリ構成

教本などでは「アプリのディレクトリにTemplateディレクトリを作成する」と記載されていることが多いので、多くの方がこんな感じの構成(アプリごとにTemplateがある構成)を取っているのではないかと思います。

例えばこのような構成のTemplateディレクトリがあったとします。

プロジェクト
├─ プロジェクト
│   └─ settings.py
(中略)
├─ アプリ1
│   ├─ __pycache__
│   ├─ migrations
│   ├─ templates
│   │   ├─ app01
│   │   │   ├─ index.html
│   │   │   ├─ edit.html
│   │   │   ├─ create.html
│   │   │   └─ sidnavi.html
│   │   └─ base.html
(中略)
├─ アプリ2
│   ├─ __pycache__
│   ├─ migrations
│   ├─ templates
│   │   ├─ app02
│   │   │   ├─ index.html
│   │   │   ├─ edit.html
│   │   │   ├─ create.html
│   │   │   └─ sidnavi.html
│   │   └─ footer.html
(中略)
├─ アプリ3
│   ├─ __pycache__
│   ├─ migrations
│   ├─ templates
│   │   ├─ app03
│   │   │   ├─ index.html
│   │   │   ├─ edit.html
│   │   │   ├─ create.html
│   │   │   └─ sidnavi.html
│   │   └─test.html
(中略)
└── manage.py

これ、Djangoの中では下のように見えています。

プロジェクト
├─ プロジェクト
│   └─ settings.py
(中略)
├─ アプリ1
│   ├─ __pycache__
│   ├─ migrations
│   ├─ templates
│   │   ├─ app01
│   │   │   ├─ index.html
│   │   │   ├─ edit.html
│   │   │   ├─ create.html
│   │   │   └─ sidnavi.html
│   │   ├─ app02
│   │   │   ├─ index.html
│   │   │   ├─ edit.html
│   │   │   ├─ create.html
│   │   │   └─ sidnavi.html
│   │   ├─ app03
│   │   │   ├─ index.html
│   │   │   ├─ edit.html
│   │   │   ├─ create.html
│   │   │   └─ sidnavi.html
│   │   ├─ test.html
│   │   ├─ footer.html
│   │   └─ base.html
(中略)
├─ アプリ2
│   ├─ __pycache__
│   ├─ migrations
│   ├─ templates
│   │   ├─ app01
│   │   │   ├─ index.html
│   │   │   ├─ edit.html
│   │   │   ├─ create.html
│   │   │   └─ sidnavi.html
(中略)
├─ アプリ3
│   ├─ __pycache__
│   ├─ migrations
│   ├─ templates
│   │   ├─ app01
│   │   │   ├─ index.html
│   │   │   ├─ edit.html
│   │   │   ├─ create.html
│   │   │   └─ sidnavi.html
(中略)
└── manage.py

どのアプリから見ても『分割して書いたはず』のTemplateがまとめて置いてありますよね。
なので、共通して使う base.html のようなファイルとアプリを超えて流用しないファイルはディレクトリ名で区分けする必要があります。

Templateディレクトリの間違えた構成例

上記理由により、こんな書き方すると意図した場所を読み込まず「作ったはずのページじゃない」とか「書いてない引数がエラーを起こす」といった現象が発生します。

プロジェクト
├─ プロジェクト
│   └─ settings.py
(中略)
├─ アプリ1
│   ├─ __pycache__
│   ├─ migrations
│   ├─ templates
│   │   ├─ CRUD
│   │   │   ├─ index.html
│   │   │   ├─ edit.html
│   │   │   └─ create.html
│   │   ├─ sidnavi.html
│   │   ├─ base.html
│   │   └─ footer.html
(中略)
├─ アプリ2
│   ├─ __pycache__
│   ├─ migrations
│   ├─ templates
│   │   ├─ CRUD
│   │   │   ├─ index.html
│   │   │   ├─ edit.html
│   │   │   └─ create.html
│   │   ├─ sidnavi.html
│   │   ├─ base.html
│   │   └─ footer.html
(中略)
├─ アプリ3
│   ├─ __pycache__
│   ├─ migrations
│   ├─ templates
│   │   ├─ CRUD
│   │   │   ├─ index.html
│   │   │   ├─ edit.html
│   │   │   └─ create.html
│   │   ├─ sidnavi.html
│   │   ├─ base.html
│   │   └─ footer.html
(中略)
└── manage.py

この機能はうまく使えば非常にありがたい

具体的に言えば【共通パーツ化】の実装が簡単です。

例えば「分析用のグラフ描写を外部パーツ化する」とか「内部アプリの基礎構成を共通化する」とか。

グラフ描写で具体的に流れを追ってみます。

グラフ描写の外部パーツ化について

Django:複数アプリで利用する関数を共通化する方法
この記事で書いた通り、関数はUSEすることでどのアプリからも呼び出すことができます。

そして、Templateディレクトリに配置するhtmlはどのアプリからも同一ディレクトリにあるように呼び出すことができます。例えば、アプリ1にのみGraphsディレクトリを作成した下のような構成を作ったとします。

プロジェクト
├─ プロジェクト
│   └─ settings.py
(中略)
├─ アプリ1
│   ├─ __pycache__
│   ├─ migrations
│   ├─ templates
│   │   ├─ app01
│   │   │   ├─ index.html
(中略)
│   │   ├─ Graphs
│   │   │   ├─ flot_line.html
│   │   │   ├─ echart_2bar.html
│   │   │   ├─ echart_scatter.html
│   │   │   └─ echart_line.html
│   │   ├─ base.html
│   │   └─ footer.html
(中略)
├─ アプリ2
│   ├─ __pycache__
│   ├─ migrations
│   ├─ templates
│   │   ├─ app02
│   │   │   ├─ index.html
(中略)
├─ アプリ3
│   ├─ __pycache__
│   ├─ migrations
│   ├─ templates
│   │   ├─ app03
│   │   │   ├─ index.html
(中略)
└── manage.py

この構成でアプリ1/Template/Graphs/echart_scatter.htmlを呼び出すには下のようにIncludeします。

▼アプリ1/Template/app01/index.html でInclude

▼アプリ2/Template/app02/index.html でInclude

▼アプリ3/Template/app03/index.html でInclude

全く同じですね。

描写する値は引数で JavaScript に渡すわけですからHTML的にはこんな感じで仕上がってしまいます。

■アプリ1/Template/Graphs/echart_scatter.html

EChartの分散図だったら下のJSで描写できます。

外部パーツ化のメリットとは

外部パーツ化は自分が楽になるために行う作業です。
単純な単体実装であれば、共通パーツなどは作成しない方が作業効率は増します。

理由は【このデータはこうなっている】というルールを実装で使えるからです。
例えば、X軸は日付データという確定した内容があれば『日付か確認して日付だったら表示できる姿に変更する』といった処理を踏む必要がありません。

ただし、この場合は同じようなSCRIPTを何回も書くことになります。
反復練習としてはとても良いのですが、プログラマは時間も商売道具です。
早く書き上げるに越したことはないとなれば、一回経験したもので外部パーツ化できるものは積極的にパーツ化して次の案件に生かしていけばOKですよね。

まとめ

先回の記事でグラフの外部パーツ化について触れておきながら、Templateのことは何も書かなかったなと思い記事化してみました。

さぁ、今日も頑張りましょう!