テンプレートについて思いつくままに
テンプレート、 具体的にいうとSmartyなんだけど、 なんとなく感じてる問題点を思いつくままに書きます。
サイズが大きくなる問題
- 通常ページの上から下まで全部記述するから、サイズが大きくなるし、 タグの開き-閉じの関係もわかにくい。
- プログラミングでいうところの関数みたいなことでどうにかなるか。
- Smartyであれば{include}。これは関数のようにも使える。
- つまりヘッダ、本文、サイドバー、フッタのような 別々のテンプレートにしておく。
- 使える局面では使えるだろうな。
文章とデザインの関係
- デザインを記述するのはテンプレートをおいてほかにない。
- 文章って関数的なものなのか。 「概要説明」とう関数があって、 その中に「このページはこれこれです」とあって、 テンプレート内では{概要説明を呼ぶ}とか書いてあるとか。
- 文章の長さにまどわされずにデザイン的なタグの開く-閉じるがわかる。
- 可能なところはやっぱり{include}か。やたら長い説明文とか。
- 全ての文章を{include}するというのは変な気がする。
- 実験としてそういうコーディング作法を試してみる価値はあるかも。
リソースファイル
- 何かのファイルを差し替えると、 文章が日本語になったり英語になったりするイメージ。
- 文章とデザインの関係をつきつめていくとそうなる？
分岐の爆発
- 構造化プログラミング用語でいうところの順次はただのHTML。
- 反復はそれ用の変数に配列なりイテレータなりを入れるので、 プログラマとデザイナーとの連携は取れているはず。
- 条件分岐は爆発する可能性が高い。
- 分岐はネストの深さ、条件文のどちらも複雑になる。
- リファクタリング的にはネストした中身を適切に関数にしたり、 条件文を関数にしたりすることですっきりさせる工夫がある。
- ネストした中身を関数化するといえば{include}で大体できるか。
- 条件文を関数にするのって、本来はコントローラの仕事じゃね？
MVCモデルと作業者
- ある条件のときに何を見せるかというのは、 本来的にはコントローラの管轄だよな。
- ある条件のときに何を見せるかというのは、 作業の上ではデザイナー兼ライターの管轄になりがち。
- 結果としてコントローラは素のフラグを大量に渡して、 テンプレートのif文で表示を切り替えるようなことをしがち。
- Smartyの言語構造を駆使してプログラミングをすることはできるけど、 それってたぶん斧で釘を打つようなアレ。
Smartyには助手が要るんじゃね
- 簡易なプログラミング言語のような何か。
- 条件文あたりを吸収する。
- {assign var="flag" val=...}でもいいんじゃね？
- assignでもいいんだけど、遅延評価的な何かか。 でもそれって単にコスト的な問題で、 富豪プログラミングでは無視できるか。
暫定的まとめ
- 長すぎる文章は別ファイルにしてinclude
- if文のネストは別ファイルにしてinclude
- if文の複雑な条件は上の方で適切な名前の変数にassign
Atom Feed