【PHP】フレームワークについて語るスレ9【総合】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2007/12/11(火) 23:37:20ID:???http://pc11.2ch.net/test/read.cgi/php/1192604501/
0271nobodyさん
2007/12/20(木) 21:36:42ID:???つまり俺フォーマットか。それだけじゃ無かろうがなｗ
確かにスレ違いかも
PHPのViewの話だっけ。
ぶっちゃけテンプレートエンジンでいいんじゃね？ OOであろうが無かろうが
所詮 require の延長で、string取得してごにょごにょして echo もしくは eval なんだから
0272nobodyさん
2007/12/20(木) 21:39:12ID:???FWを使うこと自体が目的化しちゃってるやつ。
0273250
2007/12/20(木) 21:48:54ID:???もちろん俺俺フレームワークｗ
ライブラリは使いまくるけど、FWいらんかな。
でもRailsに触れてからは、これが一つのウェブプログラミングの答えだと思った。
symphonyとか使ってみようかな。
MVCとかOOPとかの議論もいいけど、一番大事なのは開発効率。
Javaの人ら見てると、どうだこれはすごい設計技術だろーみたいな
作り手の自己満足ばっかが先行してて開発効率にフォーカスしてない。
Railsはその辺はいい。
ウェブなんかほとんどオママゴトなんだから、これでええやん、みたいな。
0274nobodyさん
2007/12/20(木) 21:51:01ID:???重くなるだけな部分までクラス化してnewしまくるコードに書き換える、オブジェクト指向してるつもりなだけの論外な奴
MVCって概念だけに溺れて自分で作りにくくしてる奴もいるし
0275nobodyさん
2007/12/20(木) 21:55:14ID:???基本的には同意だが、少し間違うとコピペでいいじゃんコピペが一番速いんだから
いらんことするなってなっちゃう人も多いんだろうなと想像する
何より社長（自分の雇い主）がそれを言い出したときすごく切なくなる
たしかにそれが一番いい局面もあるんだろうけど自分にはまだそのバランスがわからんし
0276250
2007/12/20(木) 22:22:47ID:???いかに似たコードを2度書かないようにするかは永遠の課題。
最近、その辺はコードの自動生成ツールを作ることで回避してたり。
PHPはともかく、JavaやC++みたいに型あると、
型は違うけどコードのフローは同じようなのって、
クラス設計頑張ったり、テンプレート駆使したり、
上にあるDIとか使ったりするんだろうけど、
そうするとどうしても複雑になってくるよね。
何か問題起きたときソース追うのが大変。
そういうとこはコード自動生成ツール作って、そいつに重複コード吐かせちゃう。
コードのフローは素直なのにできる。デバッグも楽になれる。
重複コード書くべきでないってのは、同じコードが点在するのが問題じゃなく、
修正が一箇所で済まなくなるから。
自動生成ツールなら同じコードが散らばってても、直すのはツールだけで済む。
とか自分は思うわけですよ。
OOPで頑張るのもいいけど、こういう逃げ道もありとおもうけどな。
まぁコード自動生成を嫌がる人は多いんだけど。
0277nobodyさん
2007/12/20(木) 22:43:32ID:???ローカルでツール共有するのも手間だし
俺もサーバサイドでrubyにphp吐かせるとか狂った事やったけど、人とサーバ増やされるというので慌てて組み直したw
その辺railsって手際よくまとめてるよな
railsにPHP吐かせられないもんかなw
OOPやMVCしたいんじゃなく、一元化や効率化を徹底したいだけなんだよな、結局。
OOPやMVC、DIなんかに手法的価値がある局面はあるけど、OOPが目的になっちまうと沈む
0278nobodyさん
2007/12/20(木) 23:11:11ID:???生成されたコードをいじるなとｗ
それが出来るのなら、>>276もありかと思う
逆に、ただのソーステンプレートとしてコードジェネレータを使う
（いじること前提）なら、ポイントは生成されるソースの行数になりそう
結局railsよくできてるよなってなるんだけどｗ
0279250
2007/12/20(木) 23:17:16ID:???結局人が増えると、各々やり方の差があるからね。
その辺は、フリーになって1人でやる道に逃げて解決w
OOPやるためにOOPやってる人っているよね。
Javaの現場での話だけど、O/RマッパーはあくまでDTOであって、
Modelじゃないって考えの人がいた。
DTOって結局はテーブルと同じ構造だからDBよりの産物で、
ModelでDB的都合は隠蔽すべきって考え。
Table -> DTO(運び屋) -> Model
なわけでDTOではテーブルのカラムのgetter/setter以外の実装は一切許されず。
でも、テーブルとModelの構造は、ほとんどの場合1対1になるわけで。
やることと言えば、ModelのコンストラクタにDTOを渡してModelのメンバに格納。
ModelにDTOと同じgetter/setterを作って中でDTOのgetter/setterを呼び出し。
そして、初めてModelに実装が書ける。
結局、同じ構造のクラス2回作って手間2倍、重さ2倍、メモリ浪費2倍にさせられただけ。
テーブルにカラムが変更したときテーブルが増えたときの作業に萎え萎え。
0280250
2007/12/20(木) 23:20:22ID:???もちろんいじるのは禁止。自動生成ツールはリポジトリで管理。
さらにコミットしたときに自動的にサーバーで自動生成ツールが走る。
なんで勝手に上書きした糞野郎のコードは消えるw
0281nobodyさん
2007/12/20(木) 23:58:14ID:???それもう自動生成ツールじゃなくね？ライブラリと変わらんじゃないか
すでに生成されたものは面倒でも手動で再生成してマージさせるべきだとおもう
0282nobodyさん
2007/12/21(金) 00:02:54ID:???それはオブジェクト指向にしないといけないような複雑な機能を持ったウェブアプリはほとんどない。
例えばgmailだったら、メールをクラスで表現した方がいい。というか、クラスにするしかない。
が、世の中のほとんどのウェブアプリはDBの結果を連想配列に入れて後はそれをHTMLの中に埋め込むだけ。
オブジェクト指向の出番はない。
0284nobodyさん
2007/12/21(金) 00:10:53ID:???0285250
2007/12/21(金) 00:16:54ID:???自動生成ツールだけど2パターンあって、
1つは作ったのは手で絶対触らない＞これは出力されたコードはライブラリみたいなもんかもね
もう1つはコードのテンプレート自動作成＞Railsでモデルやテストクラスのひな形が自動でできるみたいな
俺が上で言ったのは前者ね。
>>282
ホントその程度で済む内容の開発ばっかなんだよね。
ビューにコード書くなってのは徹底すべきだが。
それをなぜJavaはてんこ盛りにしちゃうんだか・・・
とはいえ、やっぱ言語的にはOOPベースなのがいいなー
文字列とか配列とか基本的なのが、ちゃんとクラス化されてる方が好みだ。
0286250
2007/12/21(金) 00:22:40ID:???ああ、一点補足させてちょ。
この絶対いじらない自動生成部分はクラス丸ごととは限らず関数単位だったりもする。
class Hoge {
// @auto generate start
〜〜〜この中に自動生成コードを吐く〜〜〜
// @auto generate end
}
みたいに、あくまで特殊コメントの中身にだけ吐く。なんで他は好きにコード書ける。
クラス丸ごと吐くと、結局継承しないと機能拡張できないんでやめた、という経緯。
まぁこういうの激しく嫌がる人も多々いるだろうけど。
0287nobodyさん
2007/12/21(金) 00:26:37ID:???それは自動生成の運用で最低のやり方だと思う。
それなら、自分でも言ってる通り、ライブラリにするべきじゃないかな
自動生成は、あくまでも出来たコードはそのまま触らない、また、
修正があれば自動的に「全て」更新されるっていう前提が無いとただ
コードの行数を増やすだけのものになる、んじゃないかな
0290250
2007/12/21(金) 00:38:15ID:???なんか荒らしみたいなんで、そろそろ消えますね。
来年はこの手の自動生成ツールをオプソで配布したいな。
ちなみに>>286みたいなの嫌がる人、天下のMSもC#で同じことやってたお。
今はpartial使って別ファイルに吐いてるけど。
0291nobodyさん
2007/12/21(金) 00:45:39ID:???>>283
案件のレベルを引き合いに出すのは辞めにしね？
てのはなんか流れ読んでて思った事書き連ねるので長くなるけど、
人数規模での協調やデプロイ効率とかで言うと、OOPやらFW云々より、
例えば言語が静的型付けで堅いかどうかとか、
フローが定石化している環境がいいという話になってくると思うんだ。
そういう点が満たされていれば誰もが幸せかって問うと、Java案件関わった人ならあればみんな首を横に振るでしょw
クリティカルな界隈で人数規模が増えると、出来る奴の柔軟性なんて
どうでもよくて、馬鹿に間違った事をさせない仕組みが重要になっちまう。
PHPのFWの意義を語るスレにおいて、「案件のレベル」ってものすご
暴力的で寂しくなっちまう視点だと思うんだ。
ZendやCake触ってて半端な所あっても「そうそう、こういうので
いいの。こういう程度ので。ありがとZend|Cake」とかない？w
PHPに限らずLL全般だろうけど。
>>290
天下のMSはシステムハンガリアンで血吐いて以降嫌いだw
間違った理屈でも力技で平然と大規模やらかせる好例だよな
いや、個人的に嫌いながらあそこの成果物には感服しきり。
0292nobodyさん
2007/12/21(金) 00:59:39ID:???荒らしてたDOM厨のテンプレート否定派ともども詫びて吊れよ
0293nobodyさん
2007/12/21(金) 01:09:57ID:???コードジェネレータを自作するための機能まであってすごいな。
もうフレームワークを使わない理由なんてないと思う。
0294nobodyさん
2007/12/21(金) 01:15:32ID:???> 自動生成は、あくまでも出来たコードはそのまま触らない、また、
> 修正があれば自動的に「全て」更新されるっていう前提が無いとただ
自動生成でできたコードを触らないというのなら、
それはscaffoldを使うってことと同意なんだよ。
でもscaffoldだけで作れるものなんてないだろ？
だから、自動生成したものを触る ということは避けられない運命なんだよ。
0295nobodyさん
2007/12/21(金) 01:18:53ID:???あんたも消えてもいいけどなｗ
FlashもJavaScriptもOO言語ですよ PHPなんかより遙かにｗ
後は使い方だけで(ry
0296nobodyさん
2007/12/21(金) 01:21:16ID:???また、294が正しいなら、自動生成はデメリットの方が強くなる様に思う
0297nobodyさん
2007/12/21(金) 01:24:49ID:???フレームワークにライブラリってのはすでにあるんだよ。
自動生成ってのはライブラリではなく、ライブラリにすることができない
”ライブラリを使うコード”を生成しているの。
ライブラリだけあればアプリが動くかい？
どんなアプリにもありがちなCRUDの動作程度でさえ
ライブラリだけで動くものはない。
フレームワークレベルになるとscaffoldという
ライブラリを使って動作する、土台のコードが用意されるが
scaffold程度の”ライブラリを使うコード”では実用的にはならない。
0298nobodyさん
2007/12/21(金) 01:34:35ID:???それを前提に話をされてもなぁ。
あれで自動生成されてうれしいのは正直Viewおよびページ遷移部分であって、
まちがっても
$param = $request->getParam();
$db->insert($param);
// 以上、俺の妄想フレームワーク
とかいう部分ではない、と思ってるんだがな
そういったところを「自動生成」したいのか？
また、Javaみたいにsetter/getter うるさいところでは、
public function setA($a)
{
$this->_a = $a;
}
みたいなものは自動生成されるとうれしいのかもしれないけど
>>297 は違うみたいだし。
（また、出来ればこういうのはクラスの最後尾に３０行くらい改行してつけてくれ、な）
0299nobodyさん
2007/12/21(金) 01:44:31ID:???フレームワークって言葉を特別視し過ぎじゃないか？
フレームワークなんて結局んところ、特定の設計思想上に
規約や規範をセットにしてライブラリ群を提供しているだけだろ
その観点では齟齬ない話題だと思うんだけど。
>>295
現状のJavaScriptをOOPLって言うと誤解招くんじゃないの。
プロトタイプベース言語はOOPLとして認知されてるけど、
「PHPなんかより遥かに」ってのはいただけない。
実装善し悪しを語ろうにも、クラスベースと単純比較
できるもんじゃないだろう。
：そんなJSもクラスベースになろうとしてるけど、それは別の話
ActionScriptのVMはOOだけど、Flashっていうと製作環境が
混同されて不適切だと思う。
Flex/Airだって環境の名前で余計なもん含むし、現状のFlash
ランタイムはOO化する前のVMも内包してる（上に扱える）しで、混乱招く。
あの界隈、詰まらんところの説明に困るんだよな。mxmlcはjavaだしw
0300nobodyさん
2007/12/21(金) 04:08:06ID:???0301nobodyさん
2007/12/21(金) 04:26:42ID:???それ以外は馬鹿
0302nobodyさん
2007/12/21(金) 04:44:58ID:???アホどもがスレチな話題をいくらふりまこうが、
結局そこに戻る。
0303nobodyさん
2007/12/21(金) 10:05:36ID:???0304nobodyさん
2007/12/21(金) 12:01:00ID:???全ては結果が良ければなんでもいい。
理屈で間違っていても結果が良ければ問題ない。
実行結果だけじゃなくてメンテナンスや開発効率その他諸々の結果な。
オブジェクト指向だろうとなかろうと、望む要件を満たすならどっちでもいい。
満たせないのにオブジェクト指向のしがらみに囚われて実装しようとしてグダグダとかが一番最低。
んなもん全てツールの一つであって使わないといけないなんて義務もない。
それを使って結果を出せるなら使えばいいし、出せないなら使わなければいいだけの事。
0305nobodyさん
2007/12/21(金) 12:19:12ID:???こういう発想のやつって、自分の頭で開発効率あげる便利ツールとか作ったこともないんだろうな。
自動生成 = scaffoldしか頭に浮かばない。
それかレスの流れ読んでないか。
0307nobodyさん
2007/12/21(金) 21:13:22ID:???だから次に、saffoldで吐いたコードに一切手を入れず動かさなきゃいけないような事は、
現実的じゃないとか言ってる。
0308nobodyさん
2007/12/22(土) 11:38:25ID:???scaffoldで吐いたコードに手を入れないで
使えることなんてあるのか？
普通無いだろ。
お前の仕事はscaffold生成で終わりかよｗ
0309nobodyさん
2007/12/22(土) 12:01:32ID:???こんなんとFWやらOOPで仕事すんのいやだ
0310nobodyさん
2007/12/22(土) 15:38:44ID:???0311nobodyさん
2007/12/22(土) 19:57:49ID:???0312nobodyさん
2007/12/23(日) 03:49:27ID:???0313nobodyさん
2007/12/23(日) 10:26:49ID:???落ちこぼれｗｗｗｗ
0314nobodyさん
2007/12/23(日) 10:47:58ID:???昔のセフレとやったみたいな懐かしさがあるな・・・
ビッチだけど嫌いじゃない
糞言語だけど嫌いじゃない
0315nobodyさん
2007/12/23(日) 12:19:00ID:???0316nobodyさん
2007/12/23(日) 13:08:30ID:???0317nobodyさん
2007/12/23(日) 18:20:39ID:???Perl（微笑）
C#（:-）
0318nobodyさん
2007/12/23(日) 19:03:57ID:???0319nobodyさん
2007/12/23(日) 19:10:29ID:???Cも今となってはシンプルに過ぎる刀だよな
価値あるがいろいろアレだ
C++,Javaも肥大化・煩雑化を免れない代わりにお堅く作れる悩ましいアレさがある
なのでスケープゴートを用意しました。
VB（爆笑）
0320nobodyさん
2007/12/24(月) 02:21:44ID:???暴走させても致命的なことにはなりにくいけど
PHPのゆるい感覚で他の言語使ってたら
メモリ使い切ってスラッシング起こりまくりで鯖にダメージとか受ける
0321nobodyさん
2007/12/24(月) 02:24:26ID:???他のスクリプト言語=カッター
0323nobodyさん
2007/12/24(月) 11:08:21ID:???0324nobodyさん
2007/12/24(月) 11:24:54ID:???0325nobodyさん
2007/12/24(月) 15:29:48ID:???0326nobodyさん
2007/12/24(月) 17:16:28ID:???PHP的にどんなフレームワークがあればみんな楽できるんだろうな
0327nobodyさん
2007/12/24(月) 17:21:49ID:???だから、PHPのフレームワークについて語ろうぜ
0328nobodyさん
2007/12/24(月) 20:26:21ID:???試しに触ってみたぐらいでは特に不都合な所は無かったんだけど、バグがどうとかいう
評判も見るし。
普通に使えるのなら、ネイティブで組み込んでいるZend Frameworkがとても気になる。
RepositoryとかConfigとかわかりやすい部分が好感持てる。
0329nobodyさん
2007/12/24(月) 20:36:20ID:???俺が匿名で保証したところで意味ないっしょw
俺はzfを社内向けwebツール製作で便利に使ってるけど、
PDOに限らずzfは顧客向けアプリへの適用は検討してないな。
俺の良く判らんところでDBコケて、うちの鯖缶が
リコンパイルで死んでた
バグ評判に留意しつつ、自分で試行錯誤できるなら使い物にできるでしょ。
mbstring関係で困った時期に比べたら、まぁなんというんでしょうか、いいんじゃないですかね
こんな日のこんな時間にもコード書いてる自分をまあ言い聞かせてます
バグのない世界はありますか
海は死にますか
0330nobodyさん
2007/12/24(月) 21:13:55ID:???まあそうなるんだろうけど ＞ 使ってみろ
思ったが、今のPHPは（やっと）本当に過渡期で、ストレス無く云々、っていうのは
フレームワーク無しも含め、PHP5限定でやりたいような
例えばベタで書くにしても、PHP5の方がPHP4よりやりにくいって事はなさそうだし
ZendFrameworkの読みやすさの半分くらいは、PHP4を切り捨てたところにある気もする
0331nobodyさん
2007/12/25(火) 07:11:53ID:???0332nobodyさん
2007/12/25(火) 11:40:09ID:???でもPHP5なら例外使うべきだよね？
自分がつくる範囲では失敗したときに例外投げるようにしてるけど、PHP5より前に作られた関数やクラスとはどう折り合いつけてるのかな。
0333nobodyさん
2007/12/25(火) 12:01:46ID:???0334nobodyさん
2007/12/25(火) 19:23:08ID:???まあそうなんだけど、みんなそうやってる？
なんかすごく面倒なんだけど。どうしてもthrowとdieが混じってしまう。
0335nobodyさん
2007/12/25(火) 20:57:56ID:???0336nobodyさん
2007/12/25(火) 21:05:16ID:???自分で組み上げた部分に関しては、例外ってのはあくまで想定外の事が起きたときに投げるってしておくとよいよ。
でcatchする場所は基本一カ所に統括、そんで、そこでエラー出力。
たとえばstrposとかで、この局面では必ず検索対象文字列が見つかるはずなのに
falseがかえってきちゃったときは、それ以上アプリとしての処理は続けられないので
例外を投げるようにする。
falseが帰ってくることも想定できるなら、そのときの処理もしっかり書く。
dieは使わない方針でいいと思うよ。
0337nobodyさん
2007/12/26(水) 01:18:00ID:???0338nobodyさん
2007/12/26(水) 01:34:24ID:???他言語での例外を知らないから不便なだけなのかよく判らなくなるもので。
俺の知識の範疇はCやJavaScriptな駄目web土木員なもので、例外とか考察できやしない。
今ある処理を中断して名前付きのイベント投げるだけ、という腐った解釈で土方してます。
ぐぐっても判らんのでRuby弄ってたら例外なんて不要だとかいう奴がいて首傾げます
ご教示願えたら幸い程度に思ってますので論旨無視して煽ってやってください。
よろしくお願いします。
0339336
2007/12/26(水) 09:09:19ID:???例外はシステムがそれ以上続行できないケースでのみ投げる。
- DBへの接続に失敗した、DBへの読み書き中に失敗した
- 存在するはずのファイルが開けなかった
- バグと思われる分岐
で、
try {
// メイン処理
} catch (Exception ex) {
// エラー出力
}
のようにcatchする場所は、メイン処理での一カ所だけにしておく。
例外が便利なのは、メインから深いところまで入っていっても
例外さえ投げれば途中catchが無ければメイン処理のcatchまで飛んでいくこと。
基本的に自分で例外を使うときは、こういうケースでのみとしている。
仕様の範囲でユーザーの操作によって起こりうるエラーは、
きちんと分岐して適切な処理をすべきなので例外は使わない。
0340nobodyさん
2007/12/26(水) 11:39:54ID:???0341336
2007/12/26(水) 12:13:56ID:???大元の呼び出しまで一発で戻れると言うことなので。
それを望むケースって、これ以上先のコードを続行できない、続行しても無駄な時だと思う。
if〜elseで分岐してできることで例外は使わない方がいい。
try〜catch多用すると見づらくなるしね。
0342nobodyさん
2007/12/26(水) 13:23:50ID:???何となく違和感を覚える。PHP5+ZFで弄りだしたところなので
どこがどうと、うまく説明できないけど。
とりあえず、「PHPでのWebアプリに限って言えば」と断っておいた方が良くね?
0343336
2007/12/26(水) 13:40:11ID:???制御系とかは、もうちょっと勝手が変わってくる。
0344nobodyさん
2007/12/26(水) 16:55:04ID:???誰もが無視できない形でメッセージを発することができることだ
（だから通常動作範囲内では使うな）
ってコードコンプリートにも書いてたな
0345nobodyさん
2007/12/26(水) 21:18:58ID:???これは使い方次第かもしれないけど
0346nobodyさん
2007/12/27(木) 00:09:46ID:???一気に性能アップのRuby 1.9.0登場でPHP風前の灯火ｗｗｗ
0347nobodyさん
2007/12/27(木) 00:13:30ID:???0348nobodyさん
2007/12/27(木) 00:24:06ID:???これはマジでPHPﾔﾊﾞｽ
0349nobodyさん
2007/12/27(木) 00:25:56ID:???0350nobodyさん
2007/12/27(木) 00:31:00ID:???比べるならPerlとかpythonにしろ。
0351nobodyさん
2007/12/27(木) 00:31:43ID:???0352nobodyさん
2007/12/27(木) 00:39:16ID:???速いってのは、Apacheのモジュールで動かしたときに、CGIで動いている
Perlなどと比べたら、っていう世界で。
それを考慮にいれてもRubyは遅かったが、それが段違いに速くなったって
いうのは一つのトピックだとは思うな
ただRubyのリリースはまだ現状お披露目以上のもんではなさそうだ。
0353nobodyさん
2007/12/27(木) 01:34:37ID:???メモリ使用量含めた運用実績でphp5よりコンパクトになってないのはどうなんだろうな。yarv何年掛かったんだ
ただphpも全てにおいて軽い訳じゃないし細かなバグ不安はJava比で荒いし、Ruby/pythonに出来てphpにできない事がこんだけ増えると今後のトレンド荒波来てもおかしくはなさそうだねぇ。
zopeかせめてwebrickみたいなモンでもphpで作れたらどうなってただろうとか
ま、最小の構造化で大量の標準関数を使い最大の効果を。
それがPHPに実用性面の評価を与えた理由であり、適役であろうて
0354nobodyさん
2007/12/27(木) 01:50:43ID:???mod_phpは何も考えずにプログラムを書いても実用的な速度で動く。
メモリもそんなに消費しないから（これはPHPのバージョンが上がる度にメモリ食いになっていってるが）、たいていのウェブサイトなら1台のサーバで事足りる。
これはJavaにもRubyにもPerlにもない、圧倒的なPHPのメリット。
0355sage
2007/12/27(木) 01:54:09ID:???これは確かに、PHPが受け入れられ普及した、
需要があった(ある)部分なんだろうなぁ。
既に巨大なユーザベースというアドバンテージを持っている以上、
今後の舵取りで下手をこかなければそうそうシェアは引っくり返らないだろうけど、
zendはあんまりそこら変で優秀そうなイメージは無い。
0356nobodyさん
2007/12/27(木) 01:56:46ID:???なんでこのスレでやるんだよ
0357nobodyさん
2007/12/27(木) 02:09:49ID:???現状消去法もしくは消極的賛成でPHPを使ってる奴が多いってことじゃないか？
そりゃ「フレームワーク」のスレなんだから、結局目的は「うまいこと」作業をしたい
わけで、他言語に乗り換えた方がよければそうする人も多いんだろ
0358nobodyさん
2007/12/27(木) 02:44:53ID:???http://pc11.2ch.net/test/read.cgi/php/1177676518/
http://pc11.2ch.net/test/read.cgi/php/982591467/
0359nobodyさん
2007/12/27(木) 19:52:35ID:???例えばZendだとアドレスが
www.sample.com/Controller名/action名/
ってなるから、実際のファイルのディレクトリ構成とは違うじゃん？
プログラマはControllerとactionを理解してるからいいんだが、サイトには静的htmlファイルとかもあるわけで
そういうのはどうしてる？
デザイナしかさらわない部分。
そのファイルの中にはリンクもあったりして。
デザイナ的にはそこにファイルがないのに
なんでこんなリンクになるんだ？とかなると思うんだけど。
公開フォルダには殆ど実体がないし。
0360nobodyさん
2007/12/27(木) 20:02:36ID:K5rUwTQj全部自分で書き換えてるお。
そもそも、デザイナーのHTMLさえ信用してないから・・・
0361nobodyさん
2007/12/27(木) 20:16:21ID:???「xhtmlでこういうの出力します。CSS側の調整で頼みますね。画像パスはルートから指定してください」
以上。
デザイナーにhtml触らせる時代はそろそろ終わりにした方がいいと思ってます。
0362nobodyさん
2007/12/27(木) 21:42:15ID:???信用してないのは俺もなんだが、それだと意味なくねｗ
折角のコードと表示部の棲み分けがFrameworkでなってるんだから
コードに専念したい所なんだ。
>>361
↑↑のでもそうなんだけど、結局それだと動かない時にプログラマがチェックしなきゃだめじゃん？
作業量が増えるしFrameworkの利点を生かしきれてない気がするんだよなあ。
本末転倒というかなんというか。
それにデザイナにhtml触らせないと見た目カッコイイサイトできないんじゃない？
俺はデザインセンスかなりない方ってのもあるけど、やっぱ俺みたいな純PGが作るサイトって
シンプルイズベストなPGウケはしそうだけど一般人にはウケないデザインだし。
0363nobodyさん
2007/12/28(金) 01:11:25ID:zzJWz28z0364nobodyさん
2007/12/28(金) 02:22:52ID:???文書構造的にデザイン汎用性に困る場合に、意見上げてもらうことはあるけど。
0365nobodyさん
2007/12/28(金) 06:49:34ID:???そのまますべての関数を使えるPHPがどう見ても王の中の王
0366nobodyさん
2007/12/28(金) 07:46:30ID:???ゼンドとブレインウェーブが
Zend Frameworkセミナーを西日本でも開催してRuby消滅www
0369nobodyさん
2007/12/28(金) 23:42:58ID:???
■ このスレッドは過去ログ倉庫に格納されています