１．稼働サーバが広い
よく「ロリポップでも動くフレームワークにしろ」と言ってる。mod_perlが必要な時点でちょっと厳しい。もちろんPCのローカルでも動く必要がある。常にブラッシュアップを求められるのが、Webシステムなら、そのブラッシュアップするための、開発環境、検証環境は、10分で構築できるのがいい。
ssh接続を許容していないレンタルサーバもある。デザイン確認をするのにはレンタルサーバで十分。フォルダーコピーだけで動くのがいい。
２．ディレクトリを選ばない
よくあるフレームワークでは、ルート相対でないと稼働しない。キャンペーンサイトなどは、
http://クライアントのドメイン/campain/xxx
みたいなディレクトリで動くこともある。だから、ディレクトリを選ばないのが理想。
デザイナーも、ルート相対だとプレビューするのにも一苦労。だから、htmlと画像のパスはテンプレート上は相対パスの方がいい。
３．テンプレートだけを見てもプレビューができる
結構なフレームワークが、デザイナーのデザインプロセスを無視している。.tplという拡張子にしている時点でデザイナーの業務を無視している。カスタムタグも極力使わない方がいい。出来るだけ素のhtmlに近い形でプレビューしよう。
共通化したい気持も分からないでもないが、オーサリングツールにはテンプレート機能が既に備わっている。プレーンなHTMLを大量に作るしごとは多くのデザイナーがやっている。デザイナーの強みを生かそう。
３．２．URLリライターをうまく使おう
PHPはその生い立ちから、素のHTMLタグに機能を付加してくれる。例えば、
a href="index.html"
を
a href="index.html?guid=ON"
に自動的に書き換えたいときには、
output_add_rewrite_var("guid","ON");
で、自動的に書き換えてくれる。まぁ便利。この機能はフォームにも隠しフィールドを自動的に追加してくれるので、アンカーやフォームをヘルパー関数で作りこむ必要がない。
４．デバイス毎にビューの切り替えができる
もはや、PCとモバイルは両方カバーするのが当然。できれば同じURLでアクセスしたい。昨今はソーシャルメディアでURLが共有される時代。そしてソーシャルメディアのアクセスは、いよいよPCとモバイルが同じくらい。どちらも作ろう。
同じURLでもビューを切り替えることで、PCとモバイルの両方に対応が可能になる。
５．ログが取れる
これはフレームワークに限った話ではないが、何か問題があったときのよりどころはログ。開発フェーズでは、画面上にvar_dumpをしまくっていれば良かったかも知れないが、リリースされたらそういうわけにはいかない。そして本番サーバになると、ApacheのログもPHPのエラーログもアクセスできない可能性がある。アプリ開発者が意図的に出すログだけではなく、エラーログこそ「見えやすい」ところに置いておきたい。
phpでは、
set_exception_handler
set_error_handler
という関数があって、このハンドラの中で、エラーログをアプリ開発者が扱いやすい形で出力することが可能。ミドルウェアの管理の方針とアプリの管理の目的は違うのだから、ログの単位で分けて管理出来た方が良い。
