トップページ⇒php
1001コメント257KB

[PHP]フレームワークについて語るｽﾚ4[総合]

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2006/07/01(土) 07:35:07ID:Pg6bOKC2
前スレ
[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/

よく話題になるフレームワーク

■Zend Framewoek
http://framework.zend.com/
http://framework.zend.com/manual/ja/ （日本語マニュアル）

■symfony
http://www.symfony-project.com/

■[ 日本発 ] Ethna
http://ethna.jp/
0521nobodyさん2006/08/26(土) 00:10:28ID:???
<?=h($var)?>を嫌う理由がほとんどないという事実にやっと気づいたようだな。
フレームワークは必要に応じて使えばいいんだが、最悪なのはマイナーなフレームワークをさらにカスタマイズして使うこと。
0522nobodyさん2006/08/26(土) 01:09:27ID:???
マイナーじゃなくても
乗ったフレームワークが頓挫したら悲劇
例）Agavi
0523nobodyさん2006/08/26(土) 02:28:09ID:???
他人が作った「型」は要らないってことは、きっとデザインパターンとかも要らない（知らない）んだろうな…。
世の中、知らなくて損してるってことはイッパイありますね。

デザインパターン
http://www.techscore.com/tech/DesignPattern/

MVC
http://www.hyuki.com/yukiwiki/wiki.cgi?MVC

MVCは、別にPHPのフレームワークにだけ使われているわけじゃない。
Windowsを始めとする、多くのGUIアプリケーションでも使われている。

先人の努力の結晶を、受け取れる人と受け取れない人がいる。
他人の長所を称賛して、そこから学び取る人は、成長が早い。
蓋し、本人の心掛け次第。
0524nobodyさん2006/08/26(土) 02:39:41ID:???
本来のMVCとウェブのMVCはまるで別物だよ。
ウェブのMVCはIBMがこじつけただけ。
0525nobodyさん2006/08/26(土) 03:02:59ID:???
>>524
やれやれ…
0526nobodyさん2006/08/26(土) 03:29:22ID:???
ウェブアプリケーションは1リクエスト数秒で実行できる程度の処理しか出来ないし、出来る必要がない。
非ウェブアプリケーションを前提に作られたデザインパターンじゃ、ウェブアプリに適用できるのはごく限られたものしかない。
0527nobodyさん2006/08/26(土) 03:49:14ID:???
>>526
だからWebに最適化された今のMVCがあるんじゃん。
別にこじつけでもなんでもなく、３要素の分離はWebアプリだろうが全く自然な流れですが。
0528nobodyさん2006/08/26(土) 03:53:41ID:???
ウェブMVCは単にレイヤを分けただけでしょ。まあ、どう呼ぼうと勝手なのかもしれないけど。
0529nobodyさん2006/08/26(土) 06:00:36ID:???
レイヤ分けってのもあるけど、イベント駆動型をより一般化した制御反転（inversion of control）の考え方も、従来のアプリ、ウェブ、共に一躍買ってるんじゃない？
適切にメソッドを書いとけばコントローラが適切なタイミングに呼んでくれるから、呼び出すタイミングを自分でごちゃごちゃやらなくていいってやつ。
0530nobodyさん2006/08/26(土) 06:11:13ID:???
分割統治
0531nobodyさん2006/08/26(土) 08:05:42ID:???
>>529
＞適切にメソッドを書いとけばコントローラが適切なタイミングに呼んでくれる

そりゃどんな開発手法でやろうとも、「適切に」やれば全て上手くいくに決まってるじゃんか。
MVCとか何とかわざわざ小難しいこと言わんでも。
0532nobodyさん2006/08/26(土) 08:34:03ID:???
>>531
> そりゃどんな開発手法でやろうとも、「適切に」やれば全て上手くいくに決まってるじゃんか。

そうだね。基本的には程度の問題。
何を適切にやるのが簡単で、何を適切にやるのかが面倒かってだけの話。
0533nobodyさん2006/08/26(土) 09:48:59ID:???
それにしてもRubyユーザはRailsという方向へ
一点集中でどんどんよくなってるのに
PHPのFWはデファクトスタンダードが決まらず
分散しすぎなのは如何ともし難いな
どんだけ足並み揃ってないんだよって感じ
0534nobodyさん2006/08/26(土) 09:54:51ID:???
一長一短だから仕方ないお
0535nobodyさん2006/08/26(土) 10:16:07ID:???
それはPHPのWebでの使用実績が多いって事の証左でもあるっしょ。
ほぼRails一択のRubyと違って、幾つも選択肢があるというのは幸せなことだと思う。
0536nobodyさん2006/08/26(土) 10:29:15ID:???
シンプルで構造が美しくて拡張しやすくて
基本は軽くて必要なものは後から付けていけるようなフレームワークが欲しい。
ZFがそうなることを願うよ。
0537nobodyさん2006/08/26(土) 11:38:41ID:???
ZFはポテンシャル感じさせといて開発が遅いんだよな
勢いが足りないよ、勢いが
0538nobodyさん2006/08/26(土) 11:42:05ID:???
ZF1.0リリース！！→だめだ…腐ってやがる…('A`)
こんな展開きぼんぬ
0539nobodyさん2006/08/26(土) 11:57:08ID:???
ZFのコントローラやビューに興味はないけどライブラリ群はイイんで
バラのPEARパッケージを用意してほしいな。
0540nobodyさん2006/08/26(土) 12:00:23ID:???
ZF1.0リリース！！→PHP5のみに対応したPEARですた…('A`)
0541nobodyさん2006/08/26(土) 12:21:28ID:???
ぶっちゃけそれでもいい。ZFはPEARよりコーディング品質の水準が高いし。
0542nobodyさん2006/08/26(土) 12:56:32ID:???
ZFのMVCは何がマズイの？
0543nobodyさん2006/08/26(土) 13:10:54ID:???
マズくはないが
今のところすげーしょぼい
0544nobodyさん2006/08/26(土) 13:21:16ID:???
必要最低限は用意したから、あとよろしくって感じだよね。
定石はちゃんと押さえられてて、けっして悪くはないんだけど面白みに欠けるというか。
これからもイケてるフレームワークというよりは安牌として成長していくと思う。
0545nobodyさん2006/08/26(土) 13:50:53ID:???
兎にも角にも楽になればよし。
0546nobodyさん2006/08/26(土) 14:52:40ID:9tQPHWaz
PHPは名前空間がないからパッケージが作れない。
だからフレームワークを作る度に周辺ライブラリも自前で全部作ることになる。
で、異フレームワーク間でライブラリが共有できないのはもちろん、フレームワークのバージョンアップでも既存コードを使い回せず作り直しになる。
それでいつまでもたってもスタンダードが現れない。
0547nobodyさん2006/08/26(土) 15:27:06ID:???
せめてrequireするときに定義されているクラス名を付け直せればなぁ
というお話だったのさ。
0548nobodyさん2006/08/26(土) 15:51:51ID:???
まあ、クラスの命名とディレクトリとを一致させるのが多いからな

foo/bar/baz.classphp は foo_bar_baz クラスってな感じで
あとはインクルードパスを定義しなおして、自前の処理を使い回している
0549nobodyさん2006/08/26(土) 16:58:38ID:???
PHP5で
=& new $class形式で書かれてるPEAR読み込んだら
Strict Standardsって言われるんだけど
PHP5でPEAR使う奴氏ねってことですか？
0550nobodyさん2006/08/26(土) 18:00:09ID:???
>>542
543の言うとおりで、MVCに注力したものが欲しけりゃ
別のFWと組み合わせて使うべき。つか組み合わせなよと
はなから開発者も言ってた気がする。
0551nobodyさん2006/08/26(土) 18:50:15ID:???
>>549
結構そういうのってPHP4とPHP5の見えづらい
深い溝のような気がするんだよな

>>546とも関連するけど名前空間が無いから
クラス名を>>548のようにした規約の上で
PEARというライブラリを作り上げて来たのに
Strict Standadsに従うとPEARのほとんど全否定じゃんっていう
E_STRICTにしなきゃいいだけっちゃそうなんだけどさ

んでZend自らで暗黙上のPHP5版PEARを
フレームワークという名の冠つけて作ってるっていう
ZendはPEARを蔑ろにしすぎ
0552nobodyさん2006/08/26(土) 20:37:37ID:???
>>550のMVCに注力した実装って具体的にどういうこと？
0553nobodyさん2006/08/26(土) 21:11:15ID:???
symfony から ZF を使うってことだと思う
0554nobodyさん2006/08/27(日) 12:55:54ID:???
コントローラにビジネスロジックをおしつけちゃったWebMVCは
モデルが振る舞いを知らない時点で古来のMVCのうまみ半減だな。
サーバー内でMVCが完結してて、ブラウザはあくまでもフロントエンド、
ってのが楽だぞ。
フレームワーク作るほうはたいへんだが。
0555nobodyさん2006/08/27(日) 13:40:26ID:???
>>554
もうちょい具体的に頼む
0556nobodyさん2006/08/27(日) 13:49:33ID:???
コ
モ
サ
っ
フ
0557nobodyさん2006/08/27(日) 15:00:17ID:???
>>554
何を書いているのかがさっぱり分からん

コントローラにビジネスロジックを押し付けてなんていないし
現状、サーバ内でMVCは完結しているだろ
というか、フロントエンドでないブラウザってのはどういう状態なんだ
0558nobodyさん2006/08/27(日) 15:15:12ID:???
>>557
> >>554
> 何を書いているのかがさっぱり分からん

確かに。

> というか、フロントエンドでないブラウザってのはどういう状態なんだ

JavaScriptでビジネスロジックとか？
そっちの方が希なケースに見えるけど。

0559nobodyさん2006/08/27(日) 15:24:19ID:???
>>557
同意。>>554は意味がわからん。

つーか、サーバ＝バックエンド、クライアント＝フロントエンド、って使い分けはHTTPプロトコルの実装の話では？
Webアプリでは、ドメインロジック＝バックエンド、プレゼンテーションロジック＝フロントエンド、だと思うけど。

ブラウザ上でのプログラム＝JavaScriptのことをフロントエンドって呼ぶ風潮もあるのかな？
05605542006/08/27(日) 15:52:15ID:???
すまんね、適当書いたつもりではないんだが。

「コントローラにビジネスロジックをおしつけちゃったWebMVC」は、たとえば
ブラウザ−アプリケーションサーバ−データベースをそれぞれＶＣＭと対応
させて解説されているようなやつ。

「サーバー内でMVCが完結」してるのはJ2EEの解説に出てくるような、JSP、
ControlerServlet、EJBをＶＣＭに対応させたようなやつ。

「フロントエンド」はユーザーへの表示装置としての
広義のクライアント−サーバ型でいうフロントエンド。

ってこと。日本語下手でごめんな。
0561nobodyさん2006/08/27(日) 16:15:28ID:???
もう全部アセンブリでいいよ
05625542006/08/27(日) 16:23:26ID:???
>>557
>フロントエンドでないブラウザってのはどういう状態なんだ
ブラウザをコントローラとして位置付けてしまった状態。

>>559
>プレゼンテーションロジック＝フロントエンド
そういう言い方は初めて聞いた、覚えとくよ。
歴史的にはユーザーに出力を伝える、文字や画像のレンダラを
フロントエンドと呼ぶのはおかしくないだろう。
0563nobodyさん2006/08/27(日) 16:50:47ID:???
で結局何が言いたいの？
05645542006/08/27(日) 16:57:06ID:???
いや、なにかすごい事を言いたいわけじゃないので。
0565nobodyさん2006/08/27(日) 18:45:20ID:???
まぁ、ただのホームページツクールじゃん？っていうフレームワークも多いがな
0566nobodyさん2006/08/27(日) 18:50:49ID:???
symfonyのことかー！
0567nobodyさん2006/08/27(日) 19:11:25ID:???
とりあえず>>554は典型的な知ったかぶりのバカってことでFA？？
0568nobodyさん2006/08/27(日) 19:32:24ID:???
>>560
なんとなく言いたいことは分かった
現状のWebMVCって言っているやつが、コントローラ要素の中をさらにMとVとCに
分けているように見えるのは仕方ないと思う
JavaScriptですら、MVCに分けようなんて動きがあるからな
0569nobodyさん2006/08/27(日) 19:47:12ID:???
>>567　理解できない事を間違ってる事にしたい気持ちはわからないでもない

>>568
JavaScriptもAjaxが絡んでくるとMVCに分けたくなるのはむしろ自然だと思う。
てかむしろ典型的なMVCの使いどころじゃないか？
0570nobodyさん2006/08/27(日) 19:53:59ID:???
コントローラにビジネスロジックを入れては「いけない」ってのは
聞いたことがあるが、逆を聞いたのは初めてだな。
0571nobodyさん2006/08/27(日) 20:16:54ID:???
Using Zend Search Lucene in a Symfony Application
http://devzone.zend.com/node/view/id/864
0572nobodyさん2006/08/27(日) 20:29:58ID:???
Javascriptはすぐにカオスになるんだけどなんか良い解決策はあるのかしら。
沢山使い回したいのにちょっと前に書いたコード見ると目を伏せたくなる。
0573nobodyさん2006/08/27(日) 22:10:56ID:???
http://itpro.nikkeibp.co.jp/article/NEWS/20060818/245941/

Zeev氏によればバージョン1.0は今年末か来年初頭にリリースされる見込み
っておせえええええ
0574nobodyさん2006/08/27(日) 22:12:22ID:???
目を伏せる
0575nobodyさん2006/08/27(日) 23:27:29ID:???
ZFのスレって
消えてね？
0576nobodyさん2006/08/28(月) 07:03:29ID:???
>>575
そういや誰か立てたのがいたなｗ
俺はこのスレがけっこう気に入ってるし、こっちで語れれば問題ないと思ってる。

1.0出たらまたZFスレ立つんだろうけど、本当に立てるべきかどうかはこのスレの流れとかZFの実際の完成度とかSymfonyと比べてどうとか考えてからにしてもらいたいな。
0577nobodyさん2006/08/28(月) 10:16:20ID:???
>>569
それで、問題ないのだが、コントローラの中にWebMVCがあり、
ビュー要素の中にも、JavaScript用のMVCができるのが、なんかいやなのだろう

このながれ自体は仕方ないがないとは思うが
0578nobodyさん2006/08/28(月) 14:01:08ID:???
>>577
つまり、ブラウザとサーバーを含む全体が単一のMVCで
まとまってないと、なんかいやっていう感覚なのかな？

俺はブラウザのJavaScriptから見るとサーバー側はモデル
の中で抽象化されてるほうがきれいだと思う方だ。

ま、感覚的なことはしょうがないな。
0579nobodyさん2006/08/28(月) 15:26:41ID:???
> JavaScript用のMVC

なにこれ？
0580nobodyさん2006/08/28(月) 17:14:34ID:???
>>579
まだ、形になったものは出ていないが
MVC構造を持った作り JavaScript でもしようという動きがある
0581nobodyさん2006/08/28(月) 17:15:15ID:???
Ajax は MVC というのとはちょっと雰囲気違うな
0582nobodyさん2006/08/28(月) 20:37:33ID:???
みんなさぁ、MVCとか何とか、新しい用語や概念を
次から次へと生み出すのはもう止めなよ。
簡単なことをわざわざ難しくしようとするのは止めなよ。

技術に疎い一般人を煙に巻いてボロ儲けしようとしている
大手企業の策略に、技術者までもがまんまとハマってどうすんのよ。
0583nobodyさん2006/08/28(月) 20:46:22ID:???
Web2.0とかはクソだけどMVCは昔からあるし代替ワードがないじゃん
0584nobodyさん2006/08/28(月) 20:50:18ID:???
人間は物事に名前を付けて、対象を認識するという習慣を持っている。

ラベルを貼って管理しないと、諸現象の「意味」を管理できないんですね。

>>582は一面において正論だと思うが、現実には無理。

我々やあらゆる存在が、永遠に変化しないならば、新しい用語や概念を使わなくても済んだだろうに。

進化の過程には、生みの苦しみ、変化が必要な場合もある。

人類は、今の生活スタイルをやめて原始人に戻ろう！と言ってももう無理だろう。
0585nobodyさん2006/08/28(月) 20:59:12ID:???
Web 2.0万歳！
AJAX万歳！
メタボリックシンドローム万歳！ｗｗっうぇ
0586nobodyさん2006/08/28(月) 21:08:39ID:???
MVCはいいだろ
Web2.0なんかと一緒にすんな
0587nobodyさん2006/08/28(月) 22:46:50ID:8TNzwmOw
大手企業の策略ってなんだろ？
0588nobodyさん2006/08/28(月) 23:41:38ID:???
>>587
3S政策
http://www.geocities.jp/ntt21c/271c-3s.html
http://kenshin.cocolog-nifty.com/column/2005/09/post_32b1.html
0589nobodyさん2006/08/28(月) 23:44:05ID:???
Pharonスレすら残ってるのに
なんでZFスレが消えたんだ(?o?)
0590nobodyさん2006/08/28(月) 23:51:58ID:???
Pharonよく見たら
イベントドリブン型のフレームワークって新しくね？
ローマ字やサイトのイケてなさ、用語のおっさんくささ（作者年配の人？）で
うち捨てられてるけど
拾えるアイデアもある気がする
0591nobodyさん2006/08/29(火) 01:30:49ID:???
イベントドリブンだとPRADOがある
3.0になってからもきっちり月1アップデートをこなしてるようだ
0592nobodyさん2006/08/29(火) 01:37:45ID:???
>>587
たとえば最近では、「IT」を「ICT」などと（無意味に）言い換えて
新たな需要を無理くり作り出そうとしているアホ企業群がありますね。

これぞ、「簡単なことや既知のものを、わざと新しく・難しくする」手法の分かりやすい例。
0593nobodyさん2006/08/29(火) 02:37:56ID:???
>>590-591
イベントドリブンって、どのWebFWにもつかわれてるコマンドパターンとほとんど一緒じゃないの？

>>589
> Pharonスレ
まだやってたのかよｗｗｗ
0594nobodyさん2006/08/29(火) 09:11:24ID:???
ウェブアプリはリクエストごとに処理を返すだけだからね。
それの繰り返しに過ぎない。
まあ、AJAXを使えば、本来のMVCに近いアプリが作れるのかも。
けど、現状のJavaScriptとブラウザの実装じゃ、デスクトップアプリ並になるのは遥か先の話だろうね。
0595nobodyさん2006/08/29(火) 10:39:14ID:???
>>592
あのチンタラ激遅国営企業か。

>>594
っていうか別にデスクトップアプリ並になる必要ないしね。
AjaxだのFlexだの、IT企業が新たな「搾取源」を見つけては
普及させようと必死になってるだけ。
0596TTNTTNTTN2006/08/29(火) 15:33:42ID:???
>>595
http://businessnomikata.blogzine.jp/guide/2006/02/guide_001_ict1_daf6.html?bid0013&adwords

中では、文系の連中が頑張ってるですよ。広告代理店も巻き込んでたりして。

非生産的なトートロジーってやつですかね。
0597nobodyさん2006/08/29(火) 18:34:06ID:???
ZF情報少ねぇー・・。
0598nobodyさん2006/08/29(火) 19:23:02ID:???
公式サイトのマニュアル読んだらだいたい分かるじゃん
フレームワークと呼べるのか？と思う程シンプルだし。
0599nobodyさん2006/08/29(火) 19:32:46ID:???
あらためて見るとマニュアルの前半の機能すげーｼｮﾎﾞいね。

Zend_Json
Zend_Log
Zend_Mail
Zend_Mime
Zend_Pdf
Zend_Search
Zend_Service_Amazon
Zend_Service_Flickr
Zend_Service_Yahoo

このへんをPEAR的に使うくらいしかないじゃん。
どう見ても「フレームワーク」は言い過ぎです。ありがとうございました。
0600nobodyさん2006/08/29(火) 19:37:58ID:???
2007年1月
ZEND PEARMWORK
降臨
乞うご期待
0601nobodyさん2006/08/29(火) 19:41:59ID:???
>>598
いや、実際マニュアルの読みやすさと習得の楽さに感動したんだけど
利用者からのサポートが実に少ないな、と
0602nobodyさん2006/08/29(火) 20:11:53ID:???
ZFのコア部分はただインターフェイスを定めただけにしか見えん。
それともこれを更に組み合わせた高機能MVCを提供するのか？
0603nobodyさん2006/08/29(火) 20:21:24ID:???
MVCはsymfonyをご利用ください。
0604nobodyさん2006/08/29(火) 21:07:53ID:???
ｾﾞﾝﾄﾞｼｮﾎﾞｰﾑﾜｰｸですね^ ^
0605nobodyさん2006/08/29(火) 21:46:23ID:???
MojabiとかMapleとかってコントローラから始まるけど、
Javaの場合フィルターから始まるらしいんだよね。
どっちがいいのかな？
0606nobodyさん2006/08/29(火) 21:56:19ID:???
PHPのフレームワークだって、フィルターから入るじゃん。
mod_rewriteというフィルターから。
0607nobodyさん2006/08/29(火) 23:09:28ID:tgUVmvKq
PHPという言語の特性上ZFを選んだほうが自然な流れで組めると思うよ
0608nobodyさん2006/08/29(火) 23:20:05ID:???
どのへんの特性?
0609nobodyさん2006/08/30(水) 01:04:23ID:???
機能が足りないのに自然とか言われても…
0610nobodyさん2006/08/30(水) 05:14:14ID:???
だからどの機能が足りないんだ?
0611nobodyさん2006/08/30(水) 06:38:19ID:???
ＺＦは個人的にはまさに自分が求めていたスタイルだけどなー。
負荷の高い検索エンジンやコミュニティなど
内部を自分自身でひたすら最適化して行く場合ZF以上の選択肢はないのでは。
とりあえずこいつで一つ掲示板を作ってみる。
0612nobodyさん2006/08/30(水) 08:16:49ID:???
まあ汎用的な機能が豊富になればなるほど、複雑かつ動作が重くなるからね。
というわけでZFどころかフレームワーク自体使わないのが最強。
0613nobodyさん2006/08/30(水) 09:43:43ID:???
>>611
その掲示板かよくある処理の部分だけでも公開してくれないですか

当方日曜プログラマですが掲示板も内部は同じような処理が多いですよね
Zend_BBSみたいのでよくある処理をまとめてくれないかと…
プロじゃないのでよくわかりませんがそういうのは現実的ではないのでしょうか？
0614nobodyさん2006/08/30(水) 12:13:20ID:???
BBSは誰でも簡単に作れる上にバリエーションがかなりあるから
出すとしてもFlickrのようにある程度コンセプトが固まったものを
コンポーネント化する流れになってしまう。
自分が色々な場面で応用したいなら自分で作るしかないんじゃないかな。
あと本当にオーソドックスなBBSで、自分で書くより開発スピードを
優先したいならCodeIgniterみたいなコンパクトなRails系FWを使うとか。
0615nobodyさん2006/08/30(水) 13:19:37ID:???
>>614
正確にはBBSではないのかも知れなかったです。
BBSだけのサイトではなく今だとどんなサイトでも掲示板、コメントシステムはあると
思うのですけど簡単そうでBBSって結構奥が深いと思うのです。

認証、スパム対策、二重投稿防止、BBコード、WYSIWYG?などなど…
そういうのがライブラリ的でもいいのであるとみんな幸せになれるかなと

#phpBBから取って来いと言われればそれまでですが、切り出しやすくなっているかどうか…
0616nobodyさん2006/08/30(水) 14:27:16ID:9+dNEl7v
MojaviからZend Frameworkへ移行しようと思う。
理由はなんかかんだで主流になると思牛。
0617nobodyさん2006/08/30(水) 14:30:41ID:9+dNEl7v
MojaviからZend Frameworkへ移行というか学習だな。ハハ
0618nobodyさん2006/08/30(水) 14:57:41ID:???
>>615を見て勉強がてら作ってみようかと思ったんだけどViewが嫌杉なんですけど。。
これってやっぱSmarty使えないんか？
0619nobodyさん2006/08/30(水) 19:36:22ID:???
そもそもZend_View自体取り外し可能
Smartyをそのまま組み込むもよし
自前のViewでやるもよし
Zend_Viewを継承する形でSmartyを組み込んでもよし
それがZFスタイルです
0620nobodyさん2006/08/30(水) 19:42:22ID:???
現状MVCはあってないようなもの。
コンポーネントは汎用というよりは
機能に特化されている。
コンポーネントで提供されてる機能を使う状況じゃなければ
ZFを使う必然性がないぽ。
0621nobodyさん2006/08/30(水) 20:28:15ID:???
>>620
その通りだけど逆にそれぞれ機能に特化してるから
FW全体で見ると汎用的だと思うぜ
コンポーネントで使いたいモノだけロードしてすぐに使える
FW内のあの機能だけ個別で使いたい、っていうのは
symfonyやcakeじゃやりにくいだろうしね、用途次第
あとCはよくできてるよMVはグダグダだけどな
■ このスレッドは過去ログ倉庫に格納されています