【PHP】フレームワークについて語るスレ13【総合】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2009/03/24(火) 01:21:08ID:???●国外産●
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】フレームワークについて語るスレ12【総合】
http://pc11.2ch.net/test/read.cgi/php/1229960175/
0002nobodyさん
2009/03/24(火) 01:21:47ID:???【PHP】フレームワークについて語るスレ12【総合】
http://pc11.2ch.net/test/read.cgi/php/1229960175/
【PHP】フレームワークについて語るスレ10【総合】 ※実質11
http://pc11.2ch.net/test/read.cgi/php/1219581817/
【PHP】フレームワークについて語るスレ10【総合】
http://pc11.2ch.net/test/read.cgi/php/1202521438/
【PHP】フレームワークについて語るスレ9【総合】
http://pc11.2ch.net/test/read.cgi/php/1197383840/
【PHP】フレームワークについて語るスレ8【総合】
http://pc11.2ch.net/test/read.cgi/php/1192604501/
【PHP】フレームワークについて語るスレ7【総合】
http://pc11.2ch.net/test/read.cgi/php/1181350116/
【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/
0003nobodyさん
2009/03/24(火) 01:28:21ID:???【PHP】フレームワーク CakePHP 6ホール目【v1.2】
http://pc11.2ch.net/test/read.cgi/php/1236563737/
【PHP】 Smarty 隔離スレ 【テンプレート】
http://pc11.2ch.net/test/read.cgi/php/1201879269/
[PHP][フレームワーク]CodeIgniterスレ
http://pc11.2ch.net/test/read.cgi/php/1177683436/
【PHP】フレームワークMapleに舌鼓
http://pc11.2ch.net/test/read.cgi/php/1122105465/
【PHP】フレームワーク Akelos
http://pc11.2ch.net/test/read.cgi/php/1187333485/
【PHP】Ethna part.2【国産フレームワーク】
http://pc11.2ch.net/test/read.cgi/php/1186096518/
2ch有志がPHPフレームワークを作るスレ
http://pc11.2ch.net/test/read.cgi/php/1172328149/
ZendFramework Part2
http://pc11.2ch.net/test/read.cgi/php/1204726884/
フランチョスとsymfony
http://pc11.2ch.net/test/read.cgi/php/1201177567/
PHP総合雑談スレ
http://pc11.2ch.net/test/read.cgi/php/1200314111/
0004nobodyさん
2009/03/24(火) 01:30:24ID:???980レス付近になったら、次スレの準備をお願いいたしますで候
では引き続きフレームワークとは関係ない話題はほどほどにしつつ適当に語りましょう
0005nobodyさん
2009/03/24(火) 14:42:00ID:???0006nobodyさん
2009/03/24(火) 15:21:25ID:vm768fgW0008nobodyさん
2009/03/26(木) 13:38:39ID:???form関係はよさげ
0009nobodyさん
2009/03/26(木) 21:29:46ID:???0010nobodyさん
2009/03/26(木) 23:29:53ID:???0011nobodyさん
2009/03/27(金) 16:24:39ID:???5.3でeregが非推奨になってるけど
pregだとマルチバイト文字列を簡単に扱えないじゃん
なめてんの？
0012nobodyさん
2009/03/27(金) 16:27:43ID:???にゃは
0013nobodyさん
2009/03/27(金) 16:46:52ID:???それなりの苦労をすればいい、ってことだろう
0014nobodyさん
2009/03/28(土) 01:24:33ID:zO5Id0L9他にメジャーな文字化け現象はあるんでしょうか？
波ダッシュ問題 の検索結果 約 69,200 件
0015nobodyさん
2009/03/28(土) 01:33:16ID:???0016nobodyさん
2009/03/28(土) 01:50:15ID:???文字化けの原因を大別すると
１．文字セット間での変換時の変換テーブルの相互互換性の問題
２．データを処理する際のエンコーディングの取り違え
だと思うんだ。もちろん上記は複合する。
んで、波ダッシュ問題っての？その原因は１の方で、これは文字コードの変換さえしなければ起こらない。
例えばPHPはUTF-8で、DBがEUC-JPとかいうわけのわからん構成でシステム組んだりするとそんなことが起こるよ、と。
もうちょっとやらしいところでは、例えばJavaで動いているEclipseでeuc-jpのコードを書いたりすると、同じ原因で波ダッシュが化けたりする。
だから、ぶっちゃけ文字コードの変換を極力避けるシステムを作ればいい。
その為にはUTF-8が一番有効ですよっていうのが脳みそシンプルで簡単なやり方。
メール送信時だけ、今のところISO-2022-JPにしなきゃいけないみたいな現状はあるけど、そのほかはほぼUTF-8でいけるはず。
さて、勉強の為にツッコミを希望しますｗ
0017nobodyさん
2009/03/28(土) 07:03:23ID:???名前からするとcakephpが一番良く思えるのですが
0018nobodyさん
2009/03/28(土) 08:47:36ID:???0021nobodyさん
2009/03/31(火) 23:28:02ID:???0022nobodyさん
2009/04/11(土) 06:56:15ID:???0023nobodyさん
2009/04/11(土) 12:47:07ID:???0024nobodyさん
2009/04/11(土) 15:02:57ID:???0025nobodyさん
2009/04/11(土) 16:47:43ID:???0026nobodyさん
2009/04/11(土) 20:06:41ID:???0027nobodyさん
2009/04/12(日) 03:24:51ID:???Hello World？
ぶっちゃけ、ページ表示で多少引っかかるくらいの重さなら許容範囲内って仕事が9割5分。
FWの差異以前に、DBの組み方であるとかサーバや回線そのものの差が、サイトの重さの差に
占めるウェイトの8割以上、とかやけくそ気味に考えることも多い。
0028nobodyさん
2009/04/12(日) 11:32:01ID:???みんな何のフレームワークをお手本に作る？
0029nobodyさん
2009/04/12(日) 11:37:31ID:???0030nobodyさん
2009/04/14(火) 19:37:42ID:???よろしくお願いします。
0031nobodyさん
2009/04/15(水) 03:19:08ID:???0032nobodyさん
2009/04/15(水) 03:55:41ID:???0034nobodyさん
2009/04/15(水) 22:14:59ID:???新しい分活発だろうし
0035nobodyさん
2009/04/16(木) 15:19:10ID:???CIは解説本を１冊読んでチュートリアルのサンプルを作ったら、１週間程度で使い方が理解できた。
紆余曲折、結局WEBアプリの作成って、DBのラッパー作りだと納得した。
スカッフォルディングは使ってないけど、今ではFW（CI）のおかげでだいぶ生産性が上がり、楽ができるようになった。
とにかく何でもいいから１つFWをものにして、それを基準にして他と比較して、他が良ければ鞍替えすればいいと思う。
CIはシンプルなので、足りない機能があればZFから借用できる。
＝解説本にZFライブラリの利用方法が解説されていた。
CIの欠点は、CIがアメリカ製なので日本の携帯端末用ページを作るには不足が多いかもしれないということ？
CakePHPとSymfonyも一応解説本に目を通したが、覚えることが多そうだったので使わなかった。
CIよりも自分の開発規模・用途に適した、よさげなFWが登場したら、鞍替えすると思う。
0036nobodyさん
2009/04/16(木) 19:38:44ID:PXJUiMOk携帯不向きってのはどういう根拠？
ZendFrameworkとたいしてかわらんだろ？
0038nobodyさん
2009/04/17(金) 00:39:00ID:???0039nobodyさん
2009/04/18(土) 00:44:08ID:???0040nobodyさん
2009/04/18(土) 00:46:18ID:???PEAR使ってくれ。
ノウハウの蓄積の効用がわからんわけでもあるまいに。
また、その程度のノウハウを独占できる時代は終わってるんだぜｗ
0042nobodyさん
2009/04/18(土) 01:55:12ID:???＞その程度のノウハウを独占できる時代は終わってるんだぜｗ
まさしくその程度のノウハウだし、きっちり携帯切り分けるなら結局IPみたりするんだし、
やっぱり自前でやってもそんなに問題のあるコードが出てくるとはおもわなんだが。
>>41
ん〜、Net_UserAgent_Mobileに穴がない保証が見つからないし、あそこまでUAから
情報が必要になることもなさそうだしなぁ。
最近は、よさげな野良ライブラリ見つけたのでそれを参考に作ってみたりしたけど。
あと、インプレスが携帯電話の情報を無償提供とかやってるみたいだし、
結局PEARのライブラリの使いどころって、見えないなぁ。
004340
2009/04/18(土) 02:02:09ID:???それとはまた矛盾するかも知れない話ではあるが、少なくとも情報の集積という点で、
「よさげな野良ライブラリ」よりPEARに荷担したくなる自分もいる。
結局、あれだ。「自前で書いたほうが〜〜」に反発しただけなんだと思うわけだ。
>>42が気分を損ねて無いなら幸い。
004440
2009/04/18(土) 02:04:47ID:???> PEARで一括りにする時点で、何かが違うと感じた。
これ先にやったの俺だな。
ごめん。読み流してやって下さい
004542
2009/04/18(土) 02:32:07ID:???特に気を損ねたりはしてないです。
「自前で書いたほうが〜〜」という件については、
まぁ、3キャリアのUAを簡単に切り分ける程度のことで済むのであれば
わざわざNet_UserAgent_Mobileを取り出してこなくてもいいかな、と思ったというだけね。
UAよんで、正規表現とかで切り分けるだけなんだし、
上でも書いたように、IP見る場合はNet_UserAgent_Mobileじゃ足りないわけだし。
「よさげな野良ライブラリ」は、ライブラリの一部を切り出したブログのエントリを見て
すぐに理解できたのでやってみたってだけね。
Net_UserAgent_Mobileを理解するのが面倒だったっていう俺の怠慢でもある。
一応、その参考にしたエントリを張っとく
ttp://kwappa.txt-nifty.com/blog/2008/03/post_f7ff.html
これに、IPきりわけ機能と、XHTMLが表示できる出来ないの情報を付加したものを作りました。
0046nobodyさん
2009/04/18(土) 14:29:25ID:???だけどいいクラス名が思いつかない。なにかいい名前プリーズ。
/// つくりたいクラス
class Http {
var $request;
var $response;
function Http() {
$this->request = new Request();
$this->response = new Response();
}
}
0047nobodyさん
2009/04/18(土) 15:44:32ID:???ttp://www.google.co.jp/trends?q=cakephp%2C+symfony%2C+zend+framework%2C+yii+framework%2C+code+igniter&ctab=0&geo=jp&geor=all&date=all&sort=0
ほかは無いも同じだな。
0049nobodyさん
2009/04/18(土) 16:01:56ID:???まとめる必要なくね？
0050nobodyさん
2009/04/18(土) 16:17:18ID:???ttp://www.phpfour.com/blog/2008/01/php-http-class/
（HTTPクラス）
とか、PEARのHTTP_Requestとか
0051nobodyさん
2009/04/21(火) 05:05:52ID:TMA0XNZYSunがオラクルに買収されてMySQL脂肪
すなわちPHP脂肪ｗｗｗ
0053nobodyさん
2009/04/21(火) 15:54:29ID:???0054nobodyさん
2009/04/21(火) 18:01:27ID:???0055nobodyさん
2009/04/21(火) 22:20:27ID:8G0hNlN6http://www.cbook24.com/shop/ProductDetail.aspx?sku=9784798022574&CD=F1000049&WKCD=F1000037
0056nobodyさん
2009/04/22(水) 23:08:42ID:???0057nobodyさん
2009/04/22(水) 23:50:12ID:6FnKU0By0058nobodyさん
2009/04/23(木) 12:00:54ID:???0059nobodyさん
2009/04/23(木) 22:39:36ID:???0060nobodyさん
2009/04/26(日) 21:10:58ID:???0061nobodyさん
2009/04/27(月) 10:17:04ID:???0062nobodyさん
2009/04/27(月) 12:51:24ID:???同意。
・PHPは簡単だから、デザイナーやHTMLコーダーでもすぐに理解できる（分業が目的でもテンプレートシステムは不要）
・生PHPの方が、テンプレートの独自記法よりも多機能で便利
条件分岐や繰り返しは、生PHPで書いても可読性は確保できます
http://codeigniter.jp/user_guide_ja/general/alternative_php.html
だから、MVCのVも、Smarty等のテンプレートシステムはなくてもOK
0063nobodyさん
2009/04/27(月) 14:03:59ID:???0064nobodyさん
2009/04/27(月) 14:36:44ID:???0065nobodyさん
2009/04/27(月) 15:02:38ID:???テンプレートエンジンの思想は、PHP構文を置き換える目的では無いよ。
・デザイナに与える権限を最小限にする(PHPを直に触らせない)
・結果的にコード記述方法が統一される
・PHP以外の言語からも再利用出来る
・キャッシングや独自タグなどの拡張が楽
・可読性が生PHPと比べて高い
等メリットはあるし、ケースバイケースだね。
0066nobodyさん
2009/04/28(火) 18:10:44ID:???FWに付いているページキャッシュ機能が使えればOKでしょうか
>>64
計画はご利用的に
>>65
>・PHP以外の言語からも再利用出来る
その発想はなかった…１本！
0067nobodyさん
2009/04/28(火) 20:27:38ID:???ただHTMLもレイアウトを記述するためのものでは無いので、PHPやHTMLに毛が生えたような構文である必要はなく、
独自のテンプレート記述言語もいいかもしれない。
生産性の観点から言うとひとつのテンプレートからPC用HTML、携帯用HTML、Ajax用データetc.を吐けたりすると嬉しい。
0068nobodyさん
2009/04/29(水) 15:17:25ID:???VのところでSmarty等のテンプレートエンジンを使うか、使わないか？
HTMLの中にPHPのコードを埋め込めるから、生PHPそれ自体が一つのテンプレートエンジンとして使える。
生PHPよりも高機能なPHP製テンプレートエンジンってないから、生PHPは便利ですよ。
以前はSmarty使っていたけど、今は生PHPに戻りました＾＾
テンプレートエンジンを使う人には、それなりに理由があるだろうから、別に否定はしないけど。
0069nobodyさん
2009/04/29(水) 16:03:31ID:???lol
0070nobodyさん
2009/04/29(水) 17:32:01ID:???0071nobodyさん
2009/04/29(水) 18:06:52ID:???0074nobodyさん
2009/05/04(月) 19:33:15ID:???テンプレートの記述でちょろっと書いたらescape（または非escape）ってのが今のところベターな気がする。
生のPHPで E() とかグローバル関数を作って使ってもいいんだろうが、一気にきちゃなくなりそうだ。
0075nobodyさん
2009/05/05(火) 15:57:12ID:???例えば、
<? ?> #=> <?php ?>
<?= ?> #=> <?php echo ?>
に加えて、
<?== ?> #=> <?php echo エスケープ処理(); ?> （処理内容はPHP_INI_ALLで設定可能）
みたいなタグを追加する、とか？
こんな感じで実装されれば、ショートタグ全盛時代がくるだろうな。
0076nobodyさん
2009/05/05(火) 17:54:07ID:???0077nobodyさん
2009/05/05(火) 18:15:20ID:???<input type="text" class="hoge page" style="text-align: right;" name="hoge" value="<?php echo htmlspecialchars($hoge, ENT_QUOTES, 'UTF-8');?>"/>
<input type="text" class="hoge page" style="text-align: right;" name="hoge" value="<?== $hoge ?>"/>
うん。下の方が嬉しいな。
「文字数を節約する」のは特にメリットはないけど、
読みやすくする、その場所で大事でないことはあんまり目に入らないようにするっていうのは
とてもメリットがある。
0078nobodyさん
2009/05/05(火) 18:52:25ID:???0079nobodyさん
2009/05/05(火) 18:59:28ID:???どうせphp本体に手を入れるのなら、「出力は全て自動エスケープされる」モードを作った方がよくね。
俺は今、テンプレートに変数を割り当てた時点(FW側)で全てエスケープされるようにして、
変数にHTMLタグを割り当てた場合、テンプレート側でデコードするようにしている。
但し、>>74の言うようにオブジェクトは除いて別扱いせざるを得ない。
<?php echo や <?= なら自動エスケープ。<?== ならそのままってなほうがいい。
0080nobodyさん
2009/05/05(火) 19:13:28ID:???理屈はわかるけど、あくまでも、特殊処理をする方を特殊な書き方にした方がいいと思うな。
magic_quotesの悪い前例もあることだし。
それにそうしないと、例えばファイルに書き出すときにはモードをオフに、とかしなきゃいけなくなる。
まあおれの場合は実装の絡まない妄想だが。
0081nobodyさん
2009/05/05(火) 19:46:40ID:???安全性を考えたらdefaultでescapeのほうがいいと思うけどね。
008279
2009/05/05(火) 20:32:40ID:???ちょっと書き方が悪かった。
あくまでFWのview出力において全て自動エスケープ。
たとえば $view->display()としたときにdisplayメソッド内で自動エスケープをONにして
テンプレートスクリプト(生PHP)を処理していく感じ。
0083nobodyさん
2009/05/06(水) 03:44:19ID:???magic_quotes以上のゆとり思考だろ・・・
<?== ?> タグ程度なら、自前で実装出来そうだし、
用意された機能で実装すりゃいいんじゃねーの？
それをテンプレートエンジンと呼ぶかどうかは別にして
0084nobodyさん
2009/05/06(水) 03:50:45ID:???0086nobodyさん
2009/05/06(水) 11:41:38ID:???前段二行は、まあPHPとはそういう言語（？）だと。
他にもmb_stringの自動変換とかsafe_modeとか、もろもろの余計なお世話で
成り立ってるんだし、他の機能と比べればHTMLエスケープの標準オプション化くらい
なんてことはない。
ただ、エスケープの為だけにタグを"スクリプトでの"実装はあり得ないなｗ
後半はそういう意図に読めるが、それだけのテンプレートエンジンなんて筋が悪すぎる。
PHP拡張としてパーサレベルで実装してあれば便利かな、ってものだと思う。
0087nobodyさん
2009/05/06(水) 12:10:05ID:???{$var}で解決よ
0088nobodyさん
2009/05/06(水) 12:22:12ID:???>>68,71 （とそのちょっと前から）の流れだってば。
そりゃ現実的にはみんないろいろやってるだろうけど、
仮定の話はそんなに面白くないかな？
0089nobodyさん
2009/05/06(水) 12:54:21ID:???0090nobodyさん
2009/05/06(水) 13:24:40ID:???すごく消極的だが、前提ライブラリは少なければ少ない方がいい、とか。
Smarty以外にもテンプレートエンジンはあるし、どれも標準にはなり得ない。
最近のFWでもテンプレートエンジンを必須の前提にしていないものが大半だが、
その理由と同じってのでどうだろう。
俺は使えればSmarty使う派だから想像だけど。
0091nobodyさん
2009/05/06(水) 17:24:24ID:???実装出来る手段が用意されていて、特別困るものでも無いのに標準機能として盛り込んでしまうと、
裏側の処理を理解していないゆとりPGが泥沼にはまるのが目に見えるわ・・・
そもそもPHPはHTMLを出力するためだけのモノでも無いし、
HTML出力に関しても100%エスケープが必要なものでもない。
0092nobodyさん
2009/05/06(水) 19:26:56ID:???> 大半の環境ではオフにされているんだが・・・
これらがデフォルトになったのはごく最近の話って認識なんだが。
register_globalsだけが少し早かったと。
実際今までだってここら辺に嵌るのがある意味通過儀礼のようなもんだっただろｗ
んで、逆にそういう知識が常識として定着した現状なら、いろんな機能がついてても
それほど問題にもなるまいという風に考えてしまうな
0093nobodyさん
2009/05/07(木) 13:41:10ID:???0094nobodyさん
2009/05/08(金) 22:46:49ID:???0095nobodyさん
2009/05/08(金) 23:30:04ID:???これからのフレームワークは具体的にどう変化するの？
0096nobodyさん
2009/05/08(金) 23:34:42ID:???それだけではそんなに変わりそうな気もしない
何より、フレームワークはあんまりすぐには新バージョンに追随しないと思う
0097nobodyさん
2009/05/08(金) 23:54:56ID:???継承して拡張するのは楽になりそう。
0098nobodyさん
2009/05/09(土) 00:09:06ID:???これか
ttp://jp2.php.net/lsb
self::、parent:: に static:: が加わるってことでいいのかな。
しかしこれを読んだだけでは、parent::のstatic::バージョンも欲しくなりそう。
無いって事は、普通はいらないってことなのだろうか。
0099nobodyさん
2009/05/12(火) 06:50:24ID:V/2qAUy/・最初のgetInstance時に初期化パラメータを渡す
・staticなsetXXメソッドを実装して初期値を渡す
選択肢としてはこんくらい？
0100nobodyさん
2009/05/12(火) 08:28:25ID:???0101nobodyさん
2009/05/12(火) 08:45:51ID:???コンストラクタでの初期化にこだわってたけど
その方がキレイかも・・ありがとう
■ このスレッドは過去ログ倉庫に格納されています