cakephp等ってデザイナーに優しくなくない？ デザイナーとプログラマーとの分業について
某所の古いphpを最新のphpに移植しなくてはいけない、、、、
いままでrtiオレオレフレームワークだったから、そろそろcakephpとかzendとか入れようかなと思って、いろいろ調べている。
今のところ、オレオレフレームワークでデザイナーとうまい具合に分業できていたので、
流行のフレームワークとかを使えばよりデザイナーと分業できるだろうと思ってフタをあけて絶望した。。。
こいつ等は全然デザイナーに優しくないと思う。
rtiフレームワークの紹介
まずは、rtiオレオレフレームワークの説明から。
MVCではなく、、、LC+V (ライブラリ、コントローラー兼モデルw＋ビュー)な構成をとっている。
んで、パスに関していは↓な感じできわめてフラットな構成。
/lib/ライブラリ1 /lib/ライブラリ2 /モジュール/制御1.php /モジュール/制御1_画面1.tpl /モジュール/制御1_画面2.tpl /モジュール/制御1_画面3.tpl /モジュール/制御1_画面4.tpl /モジュール/制御2.php /モジュール/制御2_画面1.tpl /モジュール/制御2_画面2.tpl /モジュール/img/画像置き場
拡張子とディレクトリでアクセス制限している。
テンプレートは.tplという名前だけど、Smartyぢゃないよ。
すべてのパスは、 img/ 等のように、 相対パスで書く。 このモジュールをサーバのどこに配置しても動作するように心がける。そして何よりDreamWeaverでデザイナーが開いたときにちゃんと画面が見えるというのが最大の特徴だ。
VSセキュリティ
いや、、そこのあなた言いたいことはわかる。
不要なファイルを webroot 上に上げるなんて死んでしまえゴラァといいたいんだろう。
確かにそれはそーなんだけど、、、こいつらには、個人情報等が入っているわけではないからそこまでヒステリックになる必要もないかなぁと思うんよ。
#ログとかはwebrootより手前のアクセスできない領域だし、管理用のページはLANからしか見えない領域においている。
img/ とかと相対パスベースで書いているのでサーバのパスにアップロードしても問題なく動作するし、
何よりも、DreamWeaver で見たときにそのまま状況が再現できるっていうのが何より最大の理由だ。
デザイナーからしてみれば、DreamWeaverで見た状態で動作する画面が見えるっていうのが一番いいと思うんだ。
複雑な設定を、あーだこーだしないと、、果てはテストサーバにアップロードしてphpで動かさないと動作が確認できませんっていうのは、プログラマの勝手な理由だし、怠慢だと思うんだ。
そんな感じで、DreamWeaverで開いたらすべてがそのまま見える。
これがrtiのオレオレフレームワークのモットーなんだ。
cakephpVSデザイナー
んで、cakephpとかのフレームワークの配置を見ていくことにする。
cakephpのappの下はこんな感じになっていると思う。
controllers/モジュール1_controller.php controllers/モジュール2_controller.php views/モジュール1/画面1.ctp views/モジュール1/画面2.ctp views/モジュール2/画面1.ctp views/モジュール2/画面2.ctp views/layouts/ webroot/index.php webroot/img/画像 webroot/js/
views/モジュール1/画面1.ctp をDreamWeaverで開いたらどうなるか？
#拡張子 ctp問題はとりあえず解決済みとしておいておく。。。
画像は、別のパスにおいてあるので読むことができない。×マークでかけてしまう。
cssはどうなるか？ css定義は views/layouts/ に入っているからDreamWeaverでは読むことはできない。
結果画面は、、、画像はかけてcssは読めていない超のっぺらぼうな画面が表示される。
なんてこった。
これでデザイナーにデザインしろというのかっ！
これはあまりにもひどくないかと思うわけよ。
画像を絶対パスで書けって？
何？画像を /img/a.jpg のように絶対パスで書けって？
そして、DreamWeaverでサイトルートを設定しろ。そうしたら見えるし、cssも設定で読み込ませることが出来だろうって？
そんなふうに /img/a.jpg のような絶対パスで書いてしまうと、ソフトウェアをウェブサーバのどこに配置しても動くという汎用性が失われてしまうぢゃないか！
そして、設定すれば見えるなんてプログラマーの身勝手な理由をデザイナーに押し付ける気かと。
ユーザが /モジュール/action/ とかで起動するんだから、相対パスだったらずれてしまうだろうボケっていう人もいると思うけど、HTMLには、baseタグがあるから、それでちゃんと補正を書いておけば問題なし！
baseタグってIE4/NN4から使えるから今世の中に出ているほとんどのブラウザで問題ないと思われる。
いまどきIE3 + windows98でネットしているヤツなんていないだろうしな。
何かIE7でバグがあるらしいけど、headの内側にちゃんとおいていれば問題なし。
http://www.microsoft.com/japan/windows/ie/ie7/releasenotes/beta2.mspx
AJAX時代にはDreamweaverは意味なしって？
次、AJAX時代だから Dreamweaverとか役に立たなくね？そんなことないよん、、、多分。
rtiフレームワークはAJAXにも対応しています。。。一応。
話が脱線しちゃうんだけど、 rtiフレームワークは、HTMLにAJAXで貼り付けるHTMLって定義しておくと、フレームワークでAJAXで切り出しを行ってくれます。
何に使うかというと、ニコ動のタグみたいなもんを思い描いてほしい。タグって編集モードに入った後で編集衆望ボタンを押すと元に戻るよね。元に戻す部分を切り抜いて元のHTMLにinnerなパッチ宛てているんだろうけど、あんな感じにパッチとして当てる部分を切り抜いてくれるんだ。これでデザイナーはAJAX用のHTMLの細切れをデザインする手間が一つ減るわけさ。
ファイルがたくさんあることに対して
ファイルたくさんあると探しにくくない？ファイルを一つのディレクトにたくさん置いていると速度が遅くならない？っていう意見もあると思う。俺は全然そんなことない。エクスプローラとかでも最初の一文字を入力すればそのファイルにジャンプするぢゃん。だからファイルが400個ぐらいあっても全然平気です。特に不便と思ったことはないです。ファイル名でソートするようにしているので、制御用のモジュール名と画面テンプレートが近くに並ぶのですごく便利です。cakeやzendのフレームワークみたいに contollerやviewを別フォルダにおいているほうがあっち行ったりこっちいたりしなくてはいけずに逆に面倒と感じています。慣れの問題はあるでしょうが、、、少なくとも私にはrtiフレームワークのフォルダ構成に不便を感じたことは一度もありません。
ディレクトリのファイル数ですが、近代のファイルシステムにおいて、1万ぐらいファイルがないとパフォーマンスにはそれほど影響しないと思います。ベンチを取ったわけではないので思うとしかいえないんですが、、、逆にファイル300個程度で影響が出るなら /usr/bin とかで大変なことになるわけですから、大丈夫ではないんでしょうか。
まとめ
つーわけで、rtiフレームワークのほうがcakephp等のフレームワークよりデザイナーに優しいフレームワークだと思うわけですよ。
でも、世の中はオープンなフレームワークとかでデザイナーと分業とか高々と歌っている。
そこがわからない。
他のデザイナーの人は、これで困っていないの？
プログラマーと問題なく分業できているの？
世の中、実は分業なんてしていない？
知り合いとか、周りの人を捕まえて聞いてみると、、、
- cakephpは使っているけど、layout使うとDreamWeaverで開いたときに壊れるから使ってな。パスが変なのはプログラム書き換えて強引に直して使っている
- デザイナーが作ってくれたHTMLをプログラマーがもらって後はプログラマーが直している。デザイナーからプログラマーへは一方通行で双方向の行き来はない
- デザイナーがパワポで作った画面イメージをベースにプログラマーがHTML書いてます(涙)
とかあって、全然分業が進んでいないように思えないんですけど、、、、
納期ぎりぎりまでデザイナーとプログラマーが分業してクオリティアップな作業しているうちらが変なだけなのか、、、って思うんだよなぁ。。。
いやいや、もっとすごい方法があるに違いない。
世の中にあるもっと高度なデザイナーとプログラマーの分業のやり方をぜひ教えてください！！！
#rti フレームワークはそのうち、、、権利関係がクリアになったらw、NYSLで公開したいと思います。
#結構リライトしないといけないから来年ぐらいかなぁw、気長にお待ちください。
