トップページ⇒php
994コメント273KB

【PHP】フレームワークについて語るスレ12【総合】

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2008/12/23(火) 00:36:15ID:???
PHPのフレームワークに関する話題用のスレッド

●国外産●
symfony
　ttp://www.symfony-project.com/
code igniter
　ttp://codeigniter.com/
Zend Framework
　ttp://framework.zend.com/manual/ja/index.html
CakePHP
　ttp://www.cakephp.org/
Yii Framework　←New!! (Dec 03, 2008)
　ttp://www.yiiframework.com/

●国産
ちいたん
　ttp://php.cheetan.net/
Ethna
　ttp://ethna.jp/
guesswork
　ttp://classic.guesswork.jp/
maple
　ttp://kunit.jp/maple/

●前スレ
【PHP】フレームワークについて語るスレ10【総合】 ※実質11
http://pc11.2ch.net/test/read.cgi/php/1219581817/
0521nobodyさん2009/02/03(火) 18:40:07ID:???
>>517
そのVMって、どういう意味？
0522nobodyさん2009/02/03(火) 18:41:32ID:???
>>514
Webアプリが無料って・・・もしかして、それホームページ？
0523nobodyさん2009/02/03(火) 21:24:57ID:???
>>520
PHPで大規模なサイトも作れますね！スゴイ（・∀・）
ちなみに私のホームページは、なんと！１日１００アクセスぐらいです＞＜

サーバが１台で済むような小規模サイトなら>>503の対策で十分ですよねー？＾＾
>APCやeAccelerator等を使うのが一般的
0524nobodyさん2009/02/03(火) 21:35:53ID:???
http://www.atmarkit.co.jp/news/200809/11/ruby.html
Rubyが遅い理由
遅いのにはいくつか理由がある。
1つは変数に静的型がなく、コンパイル時に型が決まらないことから最適化が効きづらいこと。
しかし、これは動的言語共通だ。
ほかにRubyが遅い理由として前田氏はRubyには「関数がなく、すべてメソッドであること」があるという。
ただ、Rubyは次期開発バージョンのRuby1.9系ではインタープリタをまるごと差し替え、バイトコードを処理するVM を採用したことで多くの最適化を実施し、大幅に高速化しているという。

Pythonも3.0になったことだし、PHPの包囲網は強力だぞ！！！
Perl6.0は(ry
0525nobodyさん2009/02/03(火) 21:40:37ID:???
>>517
VM＝ヴァーチャルマシンのこと。
Javaの仕組みで使われて有名だよ。
http://d.hatena.ne.jp/keyword/VM
0526nobodyさん2009/02/03(火) 23:47:25ID:???
>>520
Yahoo!JapanはあんまりPHPで動いてないぞえ
知恵袋とかはそうだけど昔からある部分はCかJavaだお
0527nobodyさん2009/02/03(火) 23:49:55ID:???
Zend EngineがJavaのVMっぽいってこういうことだな
http://journal.mycom.co.jp/special/2004/php5/004.html
0528nobodyさん2009/02/03(火) 23:57:32ID:???
そ、それ2000年の記事ですけど、PHP5でもそうなの？
0529nobodyさん2009/02/04(水) 00:10:47ID:???
いったんバイトコードにコンパイルしてからVMで実行するのはPHP4でも5でも6でも同じ。
PythonやRuby 1.9でも大ざっぱに言うと同様の仕組みになってる。
あとはVM(エグセキュータ)に手を入れてia32/amd64だけでもJITコンパイラが搭載されるとおもしろいのだけど。
0530nobodyさん2009/02/04(水) 00:16:08ID:???
勉強になりました。
0531nobodyさん2009/02/04(水) 00:17:17ID:???
>>528
どうでもいいけど俺には2004年に見える
0532nobodyさん2009/02/04(水) 00:18:04ID:???
>>528
どうでもいいけど俺にはPHP5の記事に見える
0533nobodyさん2009/02/04(水) 00:37:31ID:???
>>527 >>529
普段意識してなかったけど、PHPってそうなってたんだ！
参考になりました。
0534nobodyさん2009/02/04(水) 00:46:03ID:???
PHPフレームワークの本が揃い、使いやすい状況にある。
ダントツ１位がないのは、それぞれ一長一短だからだろうか？
各FWのユーザーから、「この実装は、このFWではこうやっているよ。メリットはこれこれ。」という報告をよろしく！
FW同士、切磋琢磨していいとこ取りをしよう！

他のLL言語のメリット・デメリットはこちらもどうぞ
http://pc11.2ch.net/test/read.cgi/tech/1215319832
【Perl,PHP】LLバトルロワイヤル3【Ruby,Python】
0535nobodyさん2009/02/04(水) 00:57:47ID:???
>>534
× こちらもどうぞ
○ こちらでどうぞ

でいいだろｗ
0536nobodyさん2009/02/04(水) 01:07:12ID:???
mod_phpが常駐しないことのメリットは、なんと言ってもデプロイが簡単なことだな。単にファイルを差し替えるだけでいいんだから。
そして、これで十分なスピードがある。
スクリプト言語の処理速度の差なんて、ウェブに限って言えばどうでもいいレベル。速度差はDB部分にかかってるわけで。
0537nobodyさん2009/02/04(水) 01:20:31ID:???
いやそんなことない。
DB部分は殆どキャッシュされてるがアクセスの多いページ、例えばサイトトップとか。
0538nobodyさん2009/02/04(水) 01:22:05ID:???
重箱の隅をつつくようで悪いけど、mod_phpそのものは常駐してますやん。
バイトコードやシンボルテーブルはリクエストの度に初期化・実行・破棄されるけど。
あとは同意。
0539nobodyさん2009/02/04(水) 01:22:45ID:???
はてなとかmixiくらいになるとその差が重要になってきて
だからわざわざめんどいmod_perl使ってるんだろ
0540nobodyさん2009/02/04(水) 01:27:58ID:???
>>537
そういうのはコンテンツキャッシュでどうとでもなる。

mixiは知らんけど、はてなの場合は中の人がPerlを使える・Perlを使いたい、
かといってCGIは遅すぎるのが理由な希ガス。
0541nobodyさん2009/02/04(水) 01:28:55ID:???
mod_perlとは懐かしい響きだ
それは確かに面倒くさそうだ。てか、未だにメンテされてるの？
0542nobodyさん2009/02/04(水) 05:45:22ID:???
常駐するから速いとも一概に言えないじゃん
Rubyなんて常駐させても遅いよ
0543nobodyさん2009/02/04(水) 11:41:49ID:cqQgvAqQ
YahooはRubyだお
0544nobodyさん2009/02/04(水) 11:53:43ID:???
RubyもいいけどPHPもね
ttp://searchblog.yahoo.co.jp/2007/09/php_at_yahoo_japan.html
0545nobodyさん2009/02/04(水) 13:04:10ID:???
世紀末Web土方伝説〜LLの拳〜
例えるなら、
Python（グーグル）…ラオウ
Ruby（楽天）…トキ
PHP（Yahoo）…ケンシロウ
Perl（はてな）…ジャギ
というポジションでしょうか？（・∀・）
0546nobodyさん2009/02/04(水) 13:07:17ID:???
Perlは（現状ではなく）役割的にはリュウケンのような気もするが
0547nobodyさん2009/02/04(水) 15:41:16ID:???
わかりやすく芸人に例えてくれ
0548nobodyさん2009/02/04(水) 15:51:12ID:???
楽天はRuby殆ど使ってないぞ
99%がPHPとJava
研究してるけど全く表に出てこないｗ
0549nobodyさん2009/02/04(水) 16:13:35ID:???
わかりやすく実写版ドラゴンボールに例えてくれ
0550nobodyさん2009/02/04(水) 16:18:51ID:???
よけいわかりにくいわｗ
0551nobodyさん2009/02/04(水) 16:20:06ID:???
>>545
Rubyはトキだと思ってたらアミバだったぜ！みたいな感じか？
PHPがケンシロウってのはｗ バットかアインくらいで妥協しておけ

ECMAScript群はきっと南斗聖拳
0552nobodyさん2009/02/04(水) 16:57:49ID:???
Googleも実はPythonあんまり使ってないんだよなｗ
サービスの殆どはCとJavaで、Pythonはヘルプ機能とか軽いところしか使われてない。
0553nobodyさん2009/02/04(水) 17:28:36ID:???
Rubyはフリーザって感じだな。
出た当初は桁外れに強くて
今でも強いイメージがあるんだけど、
実はそんなでも無い？

PHPはクリリン？ あまり強いわけじゃないが
登場回数は多い。でもよくよく考えると地球人最強？

えーと、クリリンって最後の方ではフリーザより強くなったんだっけ？
0554nobodyさん2009/02/04(水) 17:36:40ID:???
ドラゴンボール戦闘力の軌跡 なんてのがあるんだなｗ
フリーザ弱っ。天津飯つえー。

http://schiphol.2ch.net/test/read.cgi/retro/1208239286/676
フリーザ；1億2000万
ヤムチャ：3億5000万
クリリン：12億6500万
天津飯：60億4500万
公式戦闘力（｢ドラゴンボール戦闘力の軌跡｣集英社より)

0555nobodyさん2009/02/04(水) 17:37:36ID:???
うん。やけくそなインフレがよくわかる

で、ここはいったい何のスレなんだｗｗｗ
0556nobodyさん2009/02/04(水) 17:41:26ID:???
ポタラ・フュージョン公式によると、もっとすごいよ。
ttp://www.geocities.jp/poposu01/katari153.html
0557nobodyさん2009/02/04(水) 17:48:28ID:???
ヤムチャなめんなよおまいら
0558nobodyさん2009/02/04(水) 18:00:45ID:???
http://www.youtube.com/watch?v=2kCo5-7sys4&hl=ja
0559nobodyさん2009/02/04(水) 23:39:35ID:???
新しい言語どんどんできたけど
結局今でもC、Java、Perl、PHPって感じだよね
0560nobodyさん2009/02/04(水) 23:45:32ID:???
ＣとPerlとはすごいよな
JavaとPHPはウェブありきで作られた面もあるからすごくて当然だけど
0561nobodyさん2009/02/05(木) 01:18:17ID:???
糞言語ばっかりだな
0562nobodyさん2009/02/05(木) 01:57:20ID:???
JavaがWebに使われるようになったの結構後だぞ
J2EEとか最初無かったから
0563nobodyさん2009/02/05(木) 09:11:17ID:???
>>562
HotJava......
0564nobodyさん2009/02/05(木) 13:50:05ID:???
Applet...
0565nobodyさん2009/02/05(木) 18:46:36ID:???
>>562
昔を知らないんだね。Appletとかちょっと書けると結構金になったもんだぞ。
0566nobodyさん2009/02/05(木) 22:25:45ID:???
>>563
糞久しぶりに聞いたｗ
0567nobodyさん2009/02/05(木) 23:19:28ID:???
C、Java、Perl、PHPの話してるんだからAppletとかそう言う問題じゃないだろうに
Flashとかとの比較になるだろそういうのは
もともとJavaはWebでApplet作るために設計された言語じゃないって事でしょ
0568nobodyさん2009/02/05(木) 23:27:54ID:???
もっともなんだが、それ以前にずーっとスレ違(ry
0569nobodyさん2009/02/06(金) 20:36:37ID:???
Javaって元々はHOTJava系で
売ろうとしてたんでしょ？
0570nobodyさん2009/02/06(金) 20:55:40ID:???
Javaはもともとは組込用のC++の代替言語として開発された
そのうちにモザイクが発表されてこれは凄いって事になって
これからはWebだなってことでHotJavaもセットになって発表された
0571nobodyさん2009/02/07(土) 08:38:14ID:???
Javaのホワイトペーパー第一版には、言語としての素晴らしさと、
中間ファイル出すから何でも動くぜーっていうのが中心として
書かれてたと思う。HotJavaはちょっと後じゃなかったっけ？
0572nobodyさん2009/02/07(土) 09:15:33ID:???
てかJavaがweb前提ってどっから出てきた発想なんだろ
0573nobodyさん2009/02/07(土) 10:10:14ID:???
>>572
どっかの勘違い君じゃない？

例のホワイトペーパーはそんなこと１つも書いてないよ。
ホワイトペーパーってのはリリース前に出すやつね。
0574nobodyさん2009/02/10(火) 00:39:54ID:???
んっとにフレームワークの話題ってないのなｗ
とりあえず、おまいらHTML5についてどう思うよ。しょうもない言語論争してるより、切実な問題じゃないか？

俺は個人的には、フォームのクライアントヴァリデート機能に期待してるんだ。
Ajaxうんちゃらかんちゃらの工数がちょっとでも省けるんなら大歓迎したい。
0575nobodyさん2009/02/10(火) 05:46:16ID:???
解説サイトの受け売りそのままですね
0576nobodyさん2009/02/10(火) 08:54:16ID:???
受け売りというか、それ以上にありがたいというか影響の大きい新機軸なんてあったかな？
0577nobodyさん2009/02/10(火) 13:37:16ID:???
>>574
クライアントヴァリデートってオマケだろ？
本当に値が正かはサーバーで見なきゃいけない。
工数省けるってのはクライアントヴァリデートのだよね？
結局サーバーサイドのヴァリデーションは面倒なままだ。
PEARで何かあるんかも知れんが。
0578nobodyさん2009/02/10(火) 21:19:58ID:???
かったりーのでクライアントヴァリデートなしで済ませる僕ってダメなやつですか？
0579nobodyさん2009/02/11(水) 00:37:33ID:???
>577
HTMLを食わせると、それと同じ基準でバリデートしてくれるライブラリが出るだろ、きっと。
最悪でも自前で実装すれば、HTML5でサイトを作っている限りは使いまわせる。
0580nobodyさん2009/02/11(水) 07:55:43ID:???
>>578
別にいいんじゃない？
>>579
楽観的だなあ。ヴァリデートの難しさは分かってるよね？
Softbankの携帯電話のみ、とか、VISAのカードでチェックデジットが
間違ってない、とか複雑なのあるし。callbackにすりゃいいんだろうけど。
あと導線というか実装がみんなまちまちなので汎用的ライブラリを作るのは
結構大変だと思われ。現存のフォームヴァリデータの実装を見てみるといい。
ケチをつけたくなるものがほとんどだ。
0581nobodyさん2009/02/11(水) 08:04:54ID:???
むしろ逆かな
サーバアプリ側のヴァリデート設定をもとにフォームのHTMLを吐き出すライブラリができる感じ？
どのみちサーバ側でのヴァリデートはしなきゃいけないんだから。
ユーザ側の入力を少しでもしやすくする部分で手が抜けるっていうのがメリットだと思う。
0582nobodyさん2009/02/11(水) 13:18:02ID:???
>581
>サーバアプリ側のヴァリデート設定をもとにフォームのHTMLを吐き出すライブラリができる
これ、結構色んなフレームワークで既に実装されているんだが。
0583nobodyさん2009/02/11(水) 15:56:29ID:???
どっちにしても下位互換しなきゃいけないんだから
作業が減るのは相当後の話だろ
0584nobodyさん2009/02/11(水) 17:48:23ID:???
クライアントヴァリデートなんてかなりどうでもいいな
そんなに付加価値ないだろ
0585nobodyさん2009/02/11(水) 20:09:31ID:???
なんでお前らヴァリヴァリ言ってんの？
0586nobodyさん2009/02/12(木) 23:00:20ID:ANumrANN
ヴァーリトゥードゥ
0587nobodyさん2009/02/12(木) 23:04:11ID:???
ヴァリヴァリヴァリヴァリヴァリタンク♪
0588nobodyさん2009/02/13(金) 20:51:25ID:???
そこはバリバリ伝説だろと小一時間(ry
0589nobodyさん2009/02/13(金) 21:29:28ID:???
cakePHPって簡単にAjax組み込める？
それともIDとか勝手に振られちゃいますか？
0590nobodyさん2009/02/13(金) 21:56:00ID:???
簡単に組み込めそうなことすらマニュアル見て試せない奴が
簡単に組み込めるとも思えないが
0591nobodyさん2009/02/13(金) 23:32:42ID:???
unixtimeが1234567890になった瞬間にPHP脂肪ｗｗｗ
0592nobodyさん2009/02/14(土) 17:06:27ID:???
ちょっとしたポータルサイトをPHPでつくろうと思っていますが、どのFWを使おうか迷っています。よかったら誰か決めてください。それにしますので。
0593nobodyさん2009/02/14(土) 17:07:54ID:???
PRADOにしてください
0594nobodyさん2009/02/14(土) 17:12:31ID:???
Zend
0595nobodyさん2009/02/14(土) 17:15:31ID:???
>>593
>>594
ありがとう。メインはPRADOにします。Zendをモジュールでつかってみます。
0596nobodyさん2009/02/14(土) 17:36:41ID:???
ちょｗ
0597nobodyさん2009/02/14(土) 19:37:42ID:???
安価でサイト作るぜ！みたいなノリだなｗ
0598nobodyさん2009/02/15(日) 02:20:01ID:???
>>597
http://baresoku.blog94.fc2.com/blog-entry-261.html
http://imakitasangyou.web.fc2.com/index.html
0599nobodyさん2009/02/19(木) 16:30:08ID:???
これってもう話題になった？
http://www.pluf.org/
0600nobodyさん2009/02/19(木) 17:24:43ID:???
>>599
へー、こんなフレームワークがあるんだー。

Pluf に一致する日本語のページ 約 710 件
まだあんまり知られていないようですね＞＜

ttp://d.hatena.ne.jp/mopemope/20090210/p1
>というか、PHPのときはrhacoでいいじゃんというのがある…

rachoはDjangoが流行る前からあったみたいですが？
ttp://project-p.jp/halt/kinowiki.php/Django%E5%8B%89%E5%BC%B7%E4%BC%9A/Disc3
0601nobodyさん2009/02/20(金) 19:06:39ID:???
フレームワークを使用して新規にECサイトを構築する場合、
管理側、ユーザ側それぞれにフレームワークを入れたほうがよいのかな。
それともフレームワークは一つで作成した方がよいのかな。
みなさんどうしてます？
0602nobodyさん2009/02/20(金) 19:10:32ID:???
同じフレームワークでもいいが、ニーズが１８０度近く違うこともあるので、
同じでもいいし違ってもいい
0603nobodyさん2009/02/20(金) 19:42:20ID:???
大抵データアクセス用のモデルクラスを作成するかと思うので、それらを使い回す為には
同じフレームワークの方がいい場合も多いかと。というか普通はそうだと思う。

それでどーーーーーーーーしても駄目な場合、もう一つフレームワーク使う・・・かなあ？
0604nobodyさん2009/02/20(金) 19:45:06ID:???
フロントZend
管理Cake
はよくやる
0605nobodyさん2009/02/20(金) 19:49:56ID:???
>>604
管理画面はscaffoldでがんがん行くってこと？
フロントに使わないのはなぜ？使いにくいの？
cake使ったこと無いからわかんね
0606nobodyさん2009/02/20(金) 20:01:45ID:???
フロントは携帯対応とかあるからCakeだと逆にめんどい
0607nobodyさん2009/02/23(月) 11:17:23ID:???
俺は>>603に同意だな。DBスキーマが二個あるのはトラブルの元だし。
scaffoldで済む程度の管理画面なら分けてもいいかもだけど。
0608nobodyさん2009/02/23(月) 18:58:21ID:???
レプリケーションしてて片方が読み専用、もう片方が書き専用なんてのは良くあるよ
だからFWも複数スキーマ対応してないと採用されづらい
0609nobodyさん2009/02/24(火) 02:11:29ID:???
>>608
複数スキーマってどういう意味？
レプリケーションなら、同一スキーマでいいんじゃね？
複数データベースという意味ならcakeは
複数のデータベースに接続できるね。
0610nobodyさん2009/02/24(火) 07:42:17ID:???
スキーマの意味を理解していないのではないかと。
0611nobodyさん2009/02/24(火) 08:47:42ID:???
今はCakeが一番流行ってるんですか？
0612nobodyさん2009/02/24(火) 08:58:35ID:???
>>609
同一スキーマにレプリケーションして意味あるのかｗ
0613nobodyさん2009/02/24(火) 13:20:18ID:???
みんなが言ってるスキーマの定義がバラバラなんじゃないか？
0614nobodyさん2009/02/24(火) 14:37:17ID:???
((lambda (x) (x x)) (lambda (x) (x x)))
0615nobodyさん2009/02/24(火) 23:50:17ID:???
log(message,leve,facility)
って感じに呼んで、
facilityによって別々のログ（ファイルやコンソール）に書き込むような
ログ機能があるFWってありますか？
0616nobodyさん2009/02/25(水) 00:38:34ID:???
>>613
どんな定義であろうと、流石にレプリケーションを同一スキーマにって奴はおらんのでは。
マシンですら別にしないと意味ないのに。
0617nobodyさん2009/02/25(水) 01:05:34ID:???
てか、
「同一スキーマにレプリケーション」とか「レプリケーションを同一スキーマに」
って、表現おかしいぞ。レプリケーションの意味わかってるのか？
0618nobodyさん2009/02/25(水) 01:10:39ID:???
とりあえずあれだ
レプリケーション（負荷分散）とか、適当に自分が念頭に置いてる訳語つけて喋れおまいら
0619nobodyさん2009/02/25(水) 01:10:40ID:???
スキーマって、DDLまたはそれの元になるデータのことを言ってるんじゃないのかな。

たとえ別サーバーであっても、同じDBMSをのっけているのなら、同じスキーマでも問題ない様に思える。

異DBMS間で、レプリケーション（マイグレーション？）するのなら、定義が変更される可能性があるので、DBMSごとにスキーマを微調整する必要はあるかもしれないけど。

>>616の反応を見てると、DSN、ユーザー名、パスワードといった接続情報も含めて、これをスキーマっていっているような気がする。
0620nobodyさん2009/02/25(水) 01:14:07ID:???
>>617
おかしいから、そんなのありえないって言ってるんじゃないのか
■ このスレッドは過去ログ倉庫に格納されています