【PHP】フレームワークについて語るスレ7【総合】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2007/06/09(土) 09:48:36ID:6f8TWb7Z【PHP】フレームワークについて語るスレ6【総合】
http://pc11.2ch.net/test/read.cgi/php/1171896620/
[PHP]フレームワークについて語るｽﾚ5[総合]
http://pc10.2ch.net/test/read.cgi/php/1159579507/
[PHP]フレームワークについて語るｽﾚ4[総合]
http://pc8.2ch.net/test/read.cgi/php/1151706907/
[PHP]フレームワークについて語るｽﾚ３[総合]
http://pc8.2ch.net/test/read.cgi/php/1145971945/
[PHP]フレームワークについて語るｽﾚ２[総合]
http://pc8.2ch.net/test/read.cgi/php/1135847024/
【PHP】フレームワークについて語るスレ【総合】
http://pc8.2ch.net/test/read.cgi/php/1123608068/
0496nobodyさん
2007/08/04(土) 22:27:45ID:???欠けるという面と、ファイルキャッシュ以外のサーバーAPI系（たとえばyoutube)の
ＰＥＡＲ実装が結局ＰＥＡＲのcache使ってるからね。どうせ導入しなきゃならないなら
最初から使わないって感じ
0497nobodyさん
2007/08/06(月) 18:54:30ID:HUsmqTvF0498nobodyさん
2007/08/08(水) 09:20:09ID:???国産フレームワークって何でマニュアルがええ加減なやつばっかなんだ？ｗ
0499nobodyさん
2007/08/08(水) 10:23:09ID:???0500nobodyさん
2007/08/08(水) 15:50:49ID:???0501nobodyさん
2007/08/08(水) 16:27:51ID:???0503nobodyさん
2007/08/08(水) 19:16:09ID:???ドキュメント化すると実態と乖離していきかねないから、
ちょっと曖昧なままにしておきたいっていうか。
すくなくとも俺はそういうのあるね。
0504nobodyさん
2007/08/08(水) 21:34:38ID:???0505nobodyさん
2007/08/08(水) 21:38:33ID:???0509nobodyさん
2007/08/08(水) 22:08:01ID:???ソース改変
だけの労力が、
ソースを改変＋ドキュメント改変
になるのがしんどいんだよ
まあ、ドキュメントを書くことでインターフェイスが簡素になるという
いい作用もあるけど…
0510nobodyさん
2007/08/08(水) 22:08:55ID:???0511nobodyさん
2007/08/08(水) 22:24:39ID:???MojaviやSymfonyに慣れてるとフロントコントローラが欲しくなるな。
アクションの遷移が従来通りだからなあ。よくもわるくも。
アクションといえば、action()がクラスじゃなくて関数での実装なのは、
ソースコピペする時に
ｸﾗｽ名変ｴﾙﾉﾓﾏﾝﾄﾞｸｾ
なんだと気付いた。Mojviじゃけっこうそんなクラスないぞって怒られたからな。
0513nobodyさん
2007/08/09(木) 00:12:52ID:???$_REQUEST上書きで十分。
てかPHP自体にバリデータがない時点でそこから発展する事になるFWなんてウンコ化は既定路線なんだがな。
0515nobodyさん
2007/08/11(土) 01:37:44ID:???貧民言語PHPm9 (^Д^)ﾌﾟｷﾞｬｰ
0516nobodyさん
2007/08/11(土) 06:53:19ID:???自分が好きな言語使ってればいいだろｗ
0517nobodyさん
2007/08/11(土) 19:22:45ID:???MVCを実現するため「だけ」のライブラリ？
0518nobodyさん
2007/08/11(土) 20:51:28ID:???が何を示しているのか理解しかねるが、
MVCの分離構造を実現するだけという意味であれば、
そのほかにもActiveRecordだのORMだのDIだの実現すんじゃね
MVCの分離構造を実現するだけでよければちいたん超おすすめｗｗｗ
0519nobodyさん
2007/08/11(土) 22:48:35ID:???ずっと生PHPだけで力任せに案件こなしてきていて、
生PHPじゃないっていうだけでなかなか受け付けないような
DQNぎみの連中対策がそろそろ必要なんだよね。
でもいきなり本格的なフレームワークだと学習コストが云々、
兵隊にはメンテさせられん云々……
とかなんとか管理職に言われてしまうよな。
それを避ける意味でも、
ちいたんに限らなくってもいいんだけど、
あのくらいの規模でコードの見通しの効くフレームワークで小さい案件やらせて
段階的にMVC開発に慣れさせるといいかもしれんと思ってる。
もちろん悩み易いconfig類のカスタマイズは先に片付けておいて、
あとはアクションとコンポーネントとテンプレート作るだけとなるように
兵隊向け作業手順のマニュアル書くんだけどな。
0520nobodyさん
2007/08/12(日) 00:15:54ID:???ちいたん初耳だった。調べてみる。
> ＞MVCを実現するため「だけ」のライブラリ
> が何を示しているのか理解しかねるが、
ごめん、質問の意図と質問文が乖離してた。
まぁFWによるんだろうけど、
PHP用のFWを使う ＝ MVCサイト構築
ってことになるのかな。
つまり。そのFWでサイト構築するには、MVC方式を余儀なくされてしまうとか。
もしそうだったら、なんかそれって「縛り」だよなぁってふと思っただけ。
>>519
DQN環境乙。
何でもかんでもMVCってのもどうかと思うけど、
とりあえずそういうときはMVCとかOOPとか、
開発手法の素晴らしさをアピールするといいかもしれん。
もうしたのかもだけど。
うちは、「一時の痛みを我慢して、その後が楽になるなら」
ってことで学習コストとか割いてくれた。
0521nobodyさん
2007/08/12(日) 00:33:30ID:???MVCサイトというのもいまいちよくわからん表現だが
そもそもフレームワークっていうのは縛りでしょ
フレームワークの提供する枠組み＝制約というのが一定のルールになって
同じフレームワークを使っている人間のコンセンサス取りやすくなったり
問題点の発見が早くなったり
そもそも問題が発生しづらくなるわけで
0522519
2007/08/12(日) 00:45:01ID:???なるほど。言う通りですよ。一部DQNなのをなんとかしたい。
ときどき手法の説明をしたり改善策として提案してるんだけど、
従来の流れと違うといまいちピンと来ないらしい。
既存案件におわれて勉強する時間もとれてないようだし。
漏れのところでいちばん効果的だったのは、
10ページくらいの小規模な案件をあっというまに片付けて、
目の前で速度差を見せつけた時かな。
慣れれば効果あるっていうのは分かったみたいだった。
規模によってはMVCでさえ大袈裟すぎる場合や、
ビューの要らないバッチ処理やインタフェース物ももちろんあるわけで。
そこは適材適所。
本格的なフレームワークで大き目の案件だと、
開発速度以上に分業しやすさとメンテ性のためにMVC開発をするんだと思ってるんだけど、
開発速度ほど有利さを披露しにくいのが難点だよね。
0523nobodyさん
2007/08/12(日) 04:41:54ID:???pradoっていうのが、確かMVCじゃなくてイベントドリブン型のどうのこうのって読んだな
http://www.pradosoft.com/demos/quickstart/index.php?page=GettingStarted.AboutPrado&lang=ja
http://hain.jp/index.php/tech-j/2007/08/06/p166
ということらしいよ。
0524nobodyさん
2007/08/12(日) 04:46:34ID:???0525nobodyさん
2007/08/12(日) 11:25:05ID:???View部分はこうだ、って言ってるだけで、そのイベントに対応するクラスはコントローラを基底に
持つと思うぜ。
0526nobodyさん
2007/08/12(日) 12:16:16ID:???0527nobodyさん
2007/08/12(日) 12:19:57ID:???0528nobodyさん
2007/08/12(日) 15:38:41ID:???0529nobodyさん
2007/08/12(日) 16:38:41ID:???0530nobodyさん
2007/08/12(日) 17:09:33ID:???0531nobodyさん
2007/08/14(火) 11:16:41ID:???Akelos
http://www.akelos.org/
0532nobodyさん
2007/08/15(水) 10:43:19ID:???このようにあえてRoRクローン風って明言した（影響を受けているとかいうんじゃなくて）ＦＷとしては、
他にどんなのがあるの？
0533nobodyさん
2007/08/15(水) 14:34:24ID:???【PHP】PHP on Rails
http://pc11.2ch.net/test/read.cgi/php/1187142925/
0534nobodyさん
2007/08/15(水) 14:41:17ID:???削除依頼だしてこいよ。
0535nobodyさん
2007/08/15(水) 14:57:18ID:???0536nobodyさん
2007/08/18(土) 16:49:31ID:XeatXWbb神本ですよっと。
http://www.cbook24.com/bm_detail.asp?sku=9784896273564
0537nobodyさん
2007/08/18(土) 18:23:53ID:???0539nobodyさん
2007/08/18(土) 20:41:35ID:???0540nobodyさん
2007/08/18(土) 21:57:37ID:???0541nobodyさん
2007/08/19(日) 23:13:36ID:???0543nobodyさん
2007/08/20(月) 19:52:44ID:???0544nobodyさん
2007/08/22(水) 01:33:27ID:???0545nobodyさん
2007/08/22(水) 08:04:04ID:4atvg3yrZend_Smartyの部分なんかがっかりしたよ。
あれじゃ、Ｓｍａｒｔｙの良さ死んどる
0546nobodyさん
2007/08/22(水) 13:40:39ID:???フォーム記入→確認顔面→投稿
この流れを簡単にしやすいFWないかな？
0547nobodyさん
2007/08/22(水) 14:22:32ID:???0548nobodyさん
2007/08/22(水) 15:33:07ID:???マニュアルをネットからダウンロードすればいいだけの話か
0549nobodyさん
2007/08/23(木) 15:37:34ID:gq3i3Qc4確認顔面というのは、投稿者の顔が不細工だとフィルタかける
っていうことですか？。FWレベルでは、そういう実装はないと思います。
0551nobodyさん
2007/08/24(金) 00:42:54ID:YoTG53/u0552nobodyさん
2007/08/24(金) 00:47:43ID:???0554nobodyさん
2007/08/25(土) 15:41:51ID:m12CHPqLダメさを今一理解していない俺に、QFの機能でダメな点を教えてくれ。
QF無しだと確認画面尽きデータ更新画面作るの超面倒臭くない？
入力値のバリデートもフィルタも。
そういう時は皆QF以外の何使ってるんでしょう。
0555nobodyさん
2007/08/25(土) 15:55:04ID:???CakePHPなどのフレームワーク。
0556nobodyさん
2007/08/25(土) 16:40:10ID:???特に入力値のバリデーションとかで
Mojaviとかのフルスタックのフレームワークに組み込みにくいという事情があった
でも今でもSymfonyとかCakeとかCIとかが持つフォームシステムで
QFほど何から何まできちんとやってくれるものはないと思う
特にバリデーションJavaScript自動生成とfreeze()あたりは
今風のフレームワークでも何らかで実装してほしいものだなー
あとQFCは死んでるしやるだけ時間の無駄だと思うｗ
0557nobodyさん
2007/08/25(土) 16:54:28ID:???2年前の記事だけど
http://hatotech.org/kumatch/archives/000475.html
一時期QFが取り上げられて流行ったけど
QFだとフォームのエレメント主導の作りになっちゃうんだな
フォームにvalidationがぶら下がっちゃうっていうか
コントローラにエレメント生成のコードが入っちゃうし
あと複雑なフォームの構成になるとトリッキーなコードになりやすかった
現状のFWなら大体フォームエレメントの生成はViewHelper、
入力値のvalidationはValidatorでやる形が主流だな
歴史的にそういう経緯があって、今こうなっているということは
結局今の形がよりベターな構成だということなんじゃないかな
0558nobodyさん
2007/08/25(土) 16:55:36ID:???>>556
自社製FWしか使った事が無くて、
それはQFを組み込んだものでして。
CIとかCakeのマニュアルを流し読み程度はしてみたものの、
面倒臭い確認画面尽きの時の画面遷移コントロールなんかがカバーされてるようには見えなくて、不思議に思ってました。
海の向こうでは確認画面あまり出さないからなのかな、とか。
フォーム要素をPHPオブジェクトと対応させるQFの発想は悪くないと思うのになぁ、とか。
まぁ、とりあえず実際にCI、Cake辺り触ってみるのが早そうですね。
0559nobodyさん
2007/08/25(土) 17:09:11ID:???確かにフォーム要素をQFでごにゃごにゃ書くのは面倒ですね。
書き方覚えるのも。個人的にはjsと同じ書き方でやらせてくれればいいのにと思います。
0560nobodyさん
2007/08/25(土) 17:36:07ID:???信頼性は皆無なので、結局サーバサイドでのバリデーションが必要になるよね。
だからバリデーションJavaScript自動生成を好んで実装したがるFW作者は少ないと思う。
フォーム要素とPHPオブジェクトのバインディングとは少し違うけど、
HTML_Template_Flexyでのフォーム要素の扱いは知っておいて損はないかも。
0561nobodyさん
2007/08/25(土) 18:24:06ID:???QFだとバリデーションをひとつ設定すればサーバサイドとクライアントサイドを自動的にやってくれるんで
信頼性をサーバサイドで確保しつつUI利便性のためクライアントサイドで……ってのが
とても簡単にできたのよ
（自作ルールセットではさすがにそうもいかないけど）
最近じゃクライアントサイドの利便性はAJAX使えってことになっちゃうのかなぁ
でもそれ自体をやりやすくしてるフレームワークってあるのかな
AJAX対応のASP.NETとかはそれに近いことをやってた気がするが……
0562nobodyさん
2007/08/25(土) 18:45:15ID:CTb1TM+mそれに、主要フレームワークはほとんどビューヘルパーとか用意してるけど、
実際問題、ベタ書きした方が正確だし、デザイナーにも易しいだろ。
0563nobodyさん
2007/08/25(土) 19:07:06ID:S/G680iY自分もそう思う。
0564nobodyさん
2007/08/25(土) 20:34:11ID:???なんだこりゃ。
0565nobodyさん
2007/08/25(土) 21:31:26ID:???フォームがDBのテーブルへの操作窓であるような概念のアプリの場合は
クラスがバリデータとかを提供する方がむしろ自然になるような設計もあると思う
QFでそれをやろうとすると、HTMLとか$_POSTとかまでQFが面倒みちゃうんで
その辺が激しく気持ち悪いことになるのが難点だけど……
HTMLについてはベタ書きよりもきちんと生成されたものの方が正確って考え方もできると思うよ
あとデザイナはフォームがどうなろうと周囲の枠だけ書けば良いような場合もあるし。
結局いつもの「適材適所で」みたいな結論になっちゃうのが残念だがなぁ
0566nobodyさん
2007/08/25(土) 21:37:02ID:S/G680iY>>556の言う「QFほど何から何まできちんとやってくれるものはないと思う」って
具体的になにをさしてるのかわからんわ。JSとか言ってるところ見ると
仔細なチェックまでFWに背負わせようとしてるんじゃないの。そんなの
スクラッチでやったほうが確実だっての。
0567nobodyさん
2007/08/25(土) 21:38:40ID:???0568nobodyさん
2007/08/25(土) 21:40:44ID:???スクラッチでやるよりも、
何もしないほうが確実ですよ？
JavaScriptはほぼ自動生成です。
仔細なチェックは当然、phpコードで書きます。
それだけで自動でJavaScriptコードが生成されるのです。
0569nobodyさん
2007/08/25(土) 21:43:58ID:???0570nobodyさん
2007/08/25(土) 21:45:52ID:???0572nobodyさん
2007/08/25(土) 21:48:56ID:???0575565
2007/08/25(土) 22:10:37ID:???べつに相手を言い負かそうとかどっちが勝ちとか考えずに
フレームワークとかフォーム処理とかの良い実装について語り合えるって程度でいいんだけどー
>>566
FWのクラスでも充分だしQFでも充分なバリデートが出来るって話でしょ。
FWの意義のひとつにはなるけどQFが不要になる理由にはならないよね。
あとQFでJSを自動生成できるのはサーバ側でできるチェックより劣るので
完全にUI利便性（POSTする前にすぐにエラーを見つけられるとかその程度）だけの問題。
0576nobodyさん
2007/08/26(日) 00:35:40ID:???フォームちょこっと変えたいだけなのに
ViewじゃなくてControllerにあるエレメント設定をいじらないといけないとか
ちょっと入力必須にしたいだけなのにエレメント設定しないといけないとか
でQFでやってるとフォームに関する全ての処理を
QFでやらないといけない感が漂ってきて
FWでMVCに沿ってるはずがだんだんQF主導のコードになっちゃうわけ
RequestもValidationもViewHelperも兼ねてるからそうならざるを得ない
多機能なライブラリが故にそれが仇となってFWに組み込みづらくなる
だからといってそれらの処理をFWによる機能とQFの機能で
中途半端に混ぜて使ってしまうともう最悪のパターンになる
だから、使わない
0577nobodyさん
2007/08/26(日) 01:05:13ID:???0578nobodyさん
2007/08/26(日) 01:52:27ID:???webベースのエディタ画面でフォームを作成すると、
それに合わせたコードが吐き出されて、
ついでにDBのテーブルも作ってくれる。
これで名実共にWeb版VBの名を欲しいままに・・。
0579nobodyさん
2007/08/26(日) 02:03:09ID:???0580nobodyさん
2007/08/26(日) 04:06:26ID:???マスタ系テーブルだけ先に手動で作らせておいて、
セレクトボックス、チェックボックス、ラジオボタンはそれを使わせる。
連関エンティティが必要になるようなフォームは自動生成からは切り捨てる。
idはサロゲートキー。
text=varchar
textarea=text
0581nobodyさん
2007/08/26(日) 04:53:39ID:???なので、JS付きのValidateしてくれるQFを見た瞬間！！！これだ！！と。
それだけなんです。JS覚えればQFなんていらないです。
でも覚えられないんです。すみませんでした。
0582nobodyさん
2007/08/26(日) 05:09:13ID:???HTMLにjsが入るのも気に食わん
0583nobodyさん
2007/08/26(日) 05:59:51ID:???ajaxでやるならともかく
QFみたいなﾀﾞｻﾀﾞｻﾁｪｯｸは素人くさいよ
まだあるっちゃあるけど
0585nobodyさん
2007/08/26(日) 08:56:04ID:???0586nobodyさん
2007/08/26(日) 09:52:19ID:???追加の機能であるJavaScriptでの検証。
それもサーバー側でのチェックと同じ機能を
二回も書くなんて面倒。
DRYの原則に反する。
自動で生成されたら楽。
0587nobodyさん
2007/08/26(日) 10:08:32ID:???でなきゃ、「UI」改善のための実装ならajax使うでしょ。
今時html埋め込みの単なるjs使う意味は？
0588nobodyさん
2007/08/26(日) 10:15:11ID:???そんなことも想定できないほど脳が腐ってますか？
0589nobodyさん
2007/08/26(日) 10:19:05ID:???貧者の発想という気がする
0590nobodyさん
2007/08/26(日) 11:03:26ID:???通信量なんか関係ないんじゃね？
0591nobodyさん
2007/08/26(日) 11:06:18ID:???0592nobodyさん
2007/08/26(日) 11:13:50ID:???当たり前すぎなんだが、そんなこも知らずに話してたんか。
だから通信が発生するAjaxは論外。
結局、否定しているやつはなんもわかってないじゃねーかｗ
0593nobodyさん
2007/08/26(日) 11:19:30ID:???> JSチェックで削減できる通信量がどれだけあるのかって話だよな
> 貧者の発想という気がする
どうやっても、JavaScriptによるレスポンスの速さを
サーバー通信が必要な方法で超えることはできんよ。
問題は通信量ではなく、すばやい反応。
そこを勘違いしていたお前の負けだ。
0594nobodyさん
2007/08/26(日) 11:42:52ID:???郵便番号から住所への変換とかはAJAXで利便性も上がる一例だけど
項目のrequiredチェックなんぞにいちいちAJAX使ったら利便性下がる一方じゃないかな。
httpdの受け口が増えまくるのはサーバ負荷管理的にもおいしくない。
それが問題にならない程度のアクセス数/サーバ数の予算が取れるなら
負荷の点は問題にしなくてもいい場合もあるが。
0595nobodyさん
2007/08/26(日) 12:30:21ID:???動的にDOMいじってサーバと通信した場合と同じ画面にするなら
まあありとも思うが
そこまで手間をかけるならもういいわってなるな。
■ このスレッドは過去ログ倉庫に格納されています