トップページ⇒php
985コメント270KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2009/03/24(火) 01:21:08ID:???
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】フレームワークについて語るスレ12【総合】
http://pc11.2ch.net/test/read.cgi/php/1229960175/
0756nobodyさん2009/09/14(月) 16:22:57ID:???
非定型ならXML、定型ならYAMLが向いてる
0757nobodyさん2009/09/14(月) 19:12:39ID:???
そろそろ>>663からの壮大なスレ違いの流れが100レスを超える

というわけで、

ここからは「自分の好きな設定ファイルのフォーマットを語るスレ」になります。
俺俺フレームワークで用いるもよし
パスの設定のみに使うもよし
PHPのバリデーションコード自体を仕込むもよし
ではどうぞ

ちなみに俺はCSV
0758nobodyさん2009/09/14(月) 20:15:54ID:???
今オススメのフレームワークってある?
俺はCakeしか使ったことがないけど、サクッと作るのにオススメのフレームワークとか他にある?
0759nobodyさん2009/09/14(月) 20:34:16ID:???
ちいたん

っていう流れをもう何度見たことか
0760nobodyさん2009/09/14(月) 20:40:01ID:???
上の方でfitzgeraldというのが紹介されてて
どうもコードが激しく短いっぽい＆超シンプルっぽいので俺の脳内タスクに記憶され中。
でもCake使いだったら、ちいたんかCIなんだろうな
0761nobodyさん2009/09/14(月) 21:36:24ID:???
じゃ Kohana を推す
07627582009/09/14(月) 22:24:36ID:???
>>759-761
ありがとう。
fitzgerald、CI、kohana、ちぃたんを検討してみる。
これらでCakePHPよりおすすめな理由ってあれば話題ついでによろしくお願いします。

ちぃたんはまじめにオススメしてくれてるんだろうか・・。
07637582009/09/14(月) 22:29:40ID:???
調べたらCIから派生したKohanaは面白そうだな〜
0764nobodyさん2009/09/15(火) 15:14:53ID:???
CI やるなら Kohana お勧め。
ユーザが少ないのが難点だけど。
0765nobodyさん2009/09/15(火) 20:46:17ID:???
>>755
> 見たことねぇわｗ

リンク先も読めないのかよｗ
http://www.ibm.com/developerworks/jp/xml/library/x-c14n/

> <?xml version="1.0" encoding="UTF-8"?>
> <doc>
> <a
> a2="2" a1="1"
> >123</a>
> </doc>

> パーサ側でホワイトスペース除くなり、該当ノード以外は無視するなりするのが定石じゃね？
なんで見やすくしようと思っただけで、
パーサー書き換えないとならんのだ。本末転倒だ。
0766nobodyさん2009/09/15(火) 21:14:29ID:???
>>765
実践でそんな書き方してる人見たことねーよ。
５年前の情報だよソレ･･･

>> パーサ側でホワイトスペース除くなり、該当ノード以外は無視するなりするのが定石じゃね？
> なんで見やすくしようと思っただけで、
> パーサー書き換えないとならんのだ。本末転倒だ。

リンク先に書かれた書き方が「見やすい」の？
XMLの仕様を理解していればそんな書き方しないで該当ノードのみを抽出するなり、ルートノードに属するテキストノードを削除するなりすると思うんだけど。

ちなみにPHPのXMLパーサは普通に対応している。
PHP読み込み時には空白データとなるが、仕様としては正常なので、
不要ならデータ処理時に省けばいいだけ。
0767nobodyさん2009/09/15(火) 23:11:03ID:???
>>765
見やすさで言えばリンク先の書き方の方が本末転倒なのではｗ
0768nobodyさん2009/09/16(水) 02:47:27ID:???
>>766
> 、ルートノードに属するテキストノードを削除するなりすると思うんだけど。
そんなことをしたら意味が変わるだろｗ

> 見やすさで言えばリンク先の書き方の方が本末転倒なのではｗ
XMLの限界だよ。
気づけよｗ

XMLは機械が生成して機械が読み込むためのものであって
人間が読み書きするものじゃない。
0769nobodyさん2009/09/16(水) 03:01:53ID:???
反論したいなら、きちんと>>754からの流れを読んで書けよな。

>>768
>> 、ルートノードに属するテキストノードを削除するなりすると思うんだけど。
>そんなことをしたら意味が変わるだろｗ

流れ的に、改行とかスペースだけの不要なテキストノードを削除しろって意味だろ？
データ的には正しい仕様なんだから、パーサのせいじゃない。

>> 見やすさで言えばリンク先の書き方の方が本末転倒なのではｗ
>XMLの限界だよ。

何がどう限界なの？改行や空白だけのデータを保持出来ない形式に変えろって事？
お前の頭の理解の限界ってこと？


>XMLは機械が生成して機械が読み込むためのものであって
>人間が読み書きするものじゃない。

ｗ　普通は機械が読み書きする専用のデータにテキスト形式なんて用いないんじゃね？
人間が読むために視覚化されてるんだろう･･･
0770nobodyさん2009/09/16(水) 03:07:04ID:???
> 流れ的に、改行とかスペースだけの不要なテキストノードを削除しろって意味だろ？

だからそれやったら意味が違うだろｗ

改行やスペースもも立派なデータだ。
スペース1個と空文字は意味が違う。
0771nobodyさん2009/09/16(水) 03:10:17ID:???
>>770
だから仕様的には正しいって書いてるだろｗ
>>754が、改行やスペースも立派なデータって事を認識しておらず、XMLは面倒とか書いてるから反論してるだけだ。
0772nobodyさん2009/09/16(水) 03:12:19ID:???
スペースが入っちゃまずいような値とかはAttributeにしときゃ
そもそもこんなアホな話題にならない

っつーかすれ違いいい加減どっか他所でやれよ
0773nobodyさん2009/09/16(水) 03:24:34ID:???
ああ、少し勘違いしていた。そういう話題じゃないか
どっちにしてもスレ違いだけどな
0774nobodyさん2009/09/16(水) 03:32:44ID:???
話題の発端自体はスレ違いじゃないんじゃね？ >>663
各フォーマットの信者がムキになっちゃってるみたいだけど･･･

個人的にはPHPなら

ini ＞ xml ≧　php　≧ JSON ≧ YAML

の順かなぁ･･･ケースバイケースだろうけど

ｉｎｉはシンプルで誰にでも解りやすいと思う
xmlは親和性の高さと、拡張性の高さが魅力
phpは簡単な設定振り分けコードも埋め込めるのが魅力
JSONはJSとの親和性が高く、他言語含めパーサの選択肢が多いのも魅力
YAMLは発展途上で、パーサ、知名度的に未知数

という感じ
0775nobodyさん2009/09/16(水) 04:00:23ID:???
iniは表現力に劣るからなあ。
0776nobodyさん2009/09/16(水) 04:26:35ID:???
おまえらもう分かったからバイナリファイル（独自フォーマット）で設定ファイル読み書きしとけ
0777nobodyさん2009/09/16(水) 04:39:06ID:???
>>775
XMLは冗長だからなあ。

要件に合わせて選択すればいい。
0778nobodyさん2009/09/16(水) 09:01:10ID:???
>>769
それは間違ってる
汎用のバイナリーフォーマットなんて極わずか
0779nobodyさん2009/09/16(水) 09:15:42ID:???
>>774
CSVはどの辺に入るかな。
偶に使われるよね、単なる設定でも。
0780nobodyさん2009/09/16(水) 10:40:10ID:???
>>778
根拠は？

>>779
CSVは設定よりデータとして扱う事が多いかな
0781nobodyさん2009/09/16(水) 17:00:02ID:???
結局良いとこどりをしたのが
今流行っているYAMLってわけだ。

ini・・・表現力に劣る
XML・・・冗長すぎる。見にくい。
php・・・データではない。コードを入れられてしまう。
JSON・・・コメントが入れられない。

YAML・・・完璧☆
0782nobodyさん2009/09/16(水) 17:04:22ID:???
ini、XML、PHP、JSON、CSVの共通の問題点として、
データの中に改行が含まれると
見づらい

YAML・・・完璧☆ﾐ
0783nobodyさん2009/09/16(水) 17:17:02ID:???
>>781がFA
0784nobodyさん2009/09/16(水) 17:18:22ID:???
YAML も複数行データは面倒じゃん。
つか、YAML を採用する新規オープンソースは少ない、
というか、ほとんどなくない？
0785nobodyさん2009/09/16(水) 17:31:19ID:???
フレームワークの神、Ruby on Railsをなんと心得ておる
0786nobodyさん2009/09/16(水) 17:49:56ID:???
>>784
XMLやHTML書いていて、改行が含まれると
<a>
　　<b>
　　　　<c>
　　　　　　<d>改行が
含まれたデータ
　　　　　　</d>
　　　　</c>
　　</b>
</a>
ってなるってわかるよね？

YAMLだとインデントが保てる
0787nobodyさん2009/09/16(水) 18:05:04ID:???
YAMLは良いとこどりしたつもりが、中途半端になった良い例。
ケースバイケースで ini / XML / php / JSON を使い分ければいい。

YAMLの利点？無いよｗ
プログラム側で無理矢理YAMLをいかそうとする設計にでもしない限りな。
0788nobodyさん2009/09/16(水) 18:10:27ID:???
>>785
Rails や Symfony 以外にも
いろんな WAF あるけど、YAML 採用のほうが少ないし、
sf.net にあるのにしても、YAML 採用なんて少ないよね、ということなんだけど。
0789nobodyさん2009/09/16(水) 19:12:45ID:???
> YAMLの利点？無いよｗ

結局良いとこどりをしたのが
今流行っているYAMLってわけだ。

ini・・・表現力に劣る
XML・・・冗長すぎる。見にくい。
php・・・データではない。コードを入れられてしまう。
JSON・・・コメントが入れられない。

YAML・・・完璧☆
0790nobodyさん2009/09/16(水) 19:51:01ID:???
>>789
YAMLはシンプルさにかけて、冗長に書くとXMLより読みづらく、PHPのような利点も無く、JSONのようにブラウザとの親和性も無い
って事？
0791nobodyさん2009/09/16(水) 19:53:09ID:???
YAMLはシンプルで読みやすく安全でJavaScriptからでも読み込めるライブラリがあるってこと。
0792nobodyさん2009/09/16(水) 20:28:51ID:???
設定ファイルでの用途について話してたんじゃねーの？なんだよブラウザって。
0793nobodyさん2009/09/16(水) 20:46:30ID:???
iniでは代替できない
JSONやPHPｼﾘｱﾗｲｽﾞは可読性に劣る

つまりXMLかYAML
JAVA世界ではXMLでRORはYAML
0794nobodyさん2009/09/16(水) 22:26:58ID:???
YAML厨はこんな所で机上の空論を展開していないで、実績を作ればいいと思うよ。
0795nobodyさん2009/09/16(水) 23:04:44ID:???
RubyならYAMLなんだけどな
YAMLは好きだが、PHPだと標準で読み出せないってのが大きな減点材料
サーバ立てるたびにspycインストールするのも面倒だし
0796nobodyさん2009/09/16(水) 23:36:50ID:???
PHPERの実務に役立つ資格って何ですか？
Zendｻｰﾃｨﾌｨｹｰｼｮﾝなんとかとかいう奴いつの間にか終わっててワロタ
0797nobodyさん2009/09/17(木) 00:40:15ID:???
>>794
それだとこのスレ解散でいいな
0798nobodyさん2009/09/17(木) 00:52:41ID:???
>>797
ここはフレームワークを語るスレだ
0799nobodyさん2009/09/17(木) 04:08:00ID:???
Rubyの場合はRubyが使える鯖を探すのから面倒だしどのみち使いづらいわなぁ
0800nobodyさん2009/09/17(木) 13:52:25ID:???
>>795
> サーバ立てるたびにspycインストールするのも面倒だし

え？　君、既存のライブラリ一切使わないの？

一昔前の人でも、PEARとか使うでしょ？
0801nobodyさん2009/09/17(木) 15:58:40ID:???
>>800
面倒じゃないことって何?
0802nobodyさん2009/09/17(木) 16:37:02ID:???
YAML厨は文脈を読まないで揚げ足取りばかり･･･('A｀
0803nobodyさん2009/09/17(木) 16:56:25ID:???
だって今時インストールなんてコマンド一行…
0804nobodyさん2009/09/17(木) 17:26:59ID:???
spycはファイル1個置いときゃいいだけなのに、
インストールが面倒とか意味わからん。
0805nobodyさん2009/09/17(木) 18:18:19ID:???
>>804
だよね。

ファイル一個置くのも面倒って
自分が作っているプログラムは、
ファイル一個でできているのかと。

自作でもいいからライブラリ使うだろう。
そしたら、ライブラリファイルを一個置くだろう。
それも面倒なんて、どれくらい初心者なんだよｗ
0806nobodyさん2009/09/17(木) 18:24:48ID:???
インストールが面倒とかじゃなくて標準で無いのが駄目って言ってるんじゃない？
08078062009/09/17(木) 18:27:02ID:???
あ、ここフレームワークスレだったか、スマン。
標準を言い出すとフレームワークどれも使えなくなるな
0808nobodyさん2009/09/17(木) 18:34:44ID:???
ZF が標準化されるかなーと思ったけど品質低いよね
0809nobodyさん2009/09/17(木) 18:39:22ID:???
標準化されれば使うところ増えるだろうね
OSにバンドルされればサポート対象にもなるし。
0810nobodyさん2009/09/17(木) 19:51:24ID:???
Google AppEngineでもYAMLは使われているね。
でもPHPでYAMLを使うのはちょっと敷居高いよ。
YAMLライブラリがRubyでは標準添付、PythonはPyYAMLのできがいいしGoogleAppEngineに含まれている、
でもspycはYAMLパーサとして不完全すぎるし、バグも多い。
YAMLはいい選択肢だと思うけど、PHPでやるのはあまりお勧めしない。
0811nobodyさん2009/09/17(木) 19:57:12ID:???
> でもspycはYAMLパーサとして不完全すぎるし、バグも多い。

いや（笑） 根拠が書いて無いから誰も信じて無いからそれｗ
0812nobodyさん2009/09/17(木) 20:19:55ID:???
Zenderとしては有り難いけどね
0813nobodyさん2009/09/17(木) 20:42:40ID:???
>>811
お前はSpyc使っているのか？あれはかなりバグ満載だぞ。
ttp://gihyo.jp/dev/serial/01/yaml_library/0004?page=3
Spycで満足しているやつはYAML初心者。
0814nobodyさん2009/09/17(木) 21:22:33ID:???
YAML？ ああ、あれは面白いフォーマットだったよね・・・。
　
　
　
って3年後に言われてるに１ペリカ
0815nobodyさん2009/09/17(木) 22:41:51ID:???
>>813
>お前はSpyc使っているのか？あれはかなりバグ満載だぞ。
つうか、バグも多いけど、YAMLの便利機能が欠けているのが痛い。使う気になれない。
Spyc使うぐらいならlibyamlの移植を使う。

>>811
>いや（笑） 根拠が書いて無いから誰も信じて無いからそれｗ
おまえがアンカーすら使ってないことはよくわかった。
その程度の知識で「YAML便利」とかほざくな。
おまえみたいなのはな、XMLが登場した時になんでもかんでもXMLで書こうとしたバカどもと同じ水準。
今はYAML覚えたてだから、なんでもかんでもYAMLで書こうとしているだけの単細胞バカ。
ミーハーの行動はYAMLの評判にとって大きなマイナス。YAMLを少しかじった程度でわかった気になるな。
0816nobodyさん2009/09/17(木) 23:24:02ID:???
XMLやJSONと比較して、パーサや情報が熟成されてない時点でなぁ･･･
全体の工数の数％程度の設定ファイルの為に、コストかけるくらいならXML書くわｗ
IDE使えば編集はYAMLより遙かに楽だし
0817nobodyさん2009/09/17(木) 23:40:00ID:???
お前らたかが設定ファイルでどんだけ熱くなってんだよｗｗ
もうarrayでいいわ
0818nobodyさん2009/09/18(金) 01:07:32ID:???
XML見づらいっていうけど、
MSのXMLエディタとか使いやすいのあるし
viにこだわらなきゃ楽じゃない？


まぁ普通は設定じゃなくて、データファイルとして使う方が多いと思うが
0819nobodyさん2009/09/18(金) 01:41:11ID:???
ループしてきた



終了
0820nobodyさん2009/09/18(金) 02:31:37ID:???
guessworkのPHP5対応版ってどうなったの？
0821nobodyさん2009/09/18(金) 07:16:54ID:???
結論
新フォーマットがどんなに優れていようと、学習環境、開発環境、実績が揃わない限り流行り物として終る。
0822nobodyさん2009/09/18(金) 09:49:02ID:???
見づらいとかは主観が入るからなぁ
メンバの多数決で決めれば良い
0823nobodyさん2009/09/18(金) 13:59:28ID:???
>>815
おろかな君に知恵を授けてあげよう。

バージョン番号。
それがあがると、バグが修正されるんだ。

お前が持ってきたリンク。0.3(beta)
最新、0.4.2

さて、何か言い訳を聞こうか？
どんなバグがあるのかね。
0824nobodyさん2009/09/18(金) 14:46:52ID:???
カレントバージョンで既知のバグすべてを直してくれる
天才プログラマの>>823がいると聞いてやってきました
0825nobodyさん2009/09/18(金) 16:18:27ID:???
バージョンが上がると、テストもせずにアップデートする>>823がいると聞いてやってきました。
0.4 って時点で未完成もいいところだろ･･･
0826nobodyさん2009/09/18(金) 17:08:39ID:???

能書きはいいから、今現在どんなバグがあるのかいってみな。

0.4.2で十分実用レベルになっているだろ。
YAMLの仕様は全部満たしていない？
だが、他の方法（iniやXML）にその仕様はあるのかと自問しよう。

YAMLは明らかに優れている。
0827nobodyさん2009/09/18(金) 17:30:58ID:???
zend studio上でcheckdnsrrを実行すると
undefined functionになるんだけど何でなの
0828nobodyさん2009/09/18(金) 17:44:47ID:???
ttp://www.php.net/manual/ja/function.checkdnsrr.php
| 5.3.0 この関数は、Windows プラットフォームでも動作するようになりました。

5.3.0 以前の Windows で使ってないよね？
0829nobodyさん2009/09/18(金) 18:17:36ID:???
>>826
なにこれ、他人を煽ってバグを見つけさせようとする新しい手口？
そこまでおまえが自信満々に語るなら、ちょっと試してみる。
0830nobodyさん2009/09/18(金) 18:20:58ID:???
>>828
つこうてました
0831nobodyさん2009/09/18(金) 18:23:38ID:???
>>830
ドンマイ
0832nobodyさん2009/09/18(金) 19:03:31ID:???
>>826
そうだね！ＹＡＭＬは凄いね！
issueすら読めない人でも使えるんだもんね！ほんとすごい！皆には内緒にしといたほうがいいよ！
0833nobodyさん2009/09/18(金) 20:30:08ID:???
そうだよ。
YAMLは凄いよ。

YAMLは仕様だからね。
ライブラリの問題は別の話。
0834nobodyさん2009/09/18(金) 20:32:24ID:???
sprcに実装していない仕様があるとはいえ、
今現在でも、iniなんかより
はるかに優れている現状をみてどう思う？
0835nobodyさん2009/09/18(金) 20:52:37ID:???
バグの出てないバージョンが出てからどうぞ。
0836nobodyさん2009/09/18(金) 21:37:03ID:???
仕様上は大は小を兼ねるのかもしれんが、
大抵の設定ファイルなんてiniで事足りる設計になってると思うよｗ

ベンチマークとか取れば、無駄なオーバーヘッドに萎えるかと。
0837nobodyさん2009/09/18(金) 21:38:48ID:???
array最強でFA
0838nobodyさん2009/09/18(金) 21:40:13ID:???
自分はZendFWのドットシンタックスなiniファイルを愛用している

database.host = "hoge"
database.user = "user"
database.password = "pass"

みたいな。
YAMLと比べるとGREPしやすくていいよ。
0839nobodyさん2009/09/18(金) 21:49:34ID:???
>>837
array()が[]で代用できるなら同意
0840nobodyさん2009/09/18(金) 22:29:27ID:???
XMLとYAMLはスキーマバリデータが使えるのも大きいよ。
素のPHPのarray()だとリストや階層構造を表現できても検証が微妙。
それに素のPHPでもない限りiniでも普通はの解析結果をキャッシュするでしょ？

まあ設定ファイルなんて各々が好きな形式を使えばいいと思うけど
自分が嫌いだからクソみたいなことを言うだけじゃ議論にならないよね。
0841nobodyさん2009/09/18(金) 23:05:58ID:???
>>838
iniファイルで、grepしやすいように、
工夫したキーにするのなら、
YAMLでも、工夫したキーにすれば同じことじゃね？
0842nobodyさん2009/09/18(金) 23:16:47ID:???
それならiniでいいじゃんってなる。
XMLのようなデータが簡単に書けるのがYAMLのいいところなんじゃないの？
0843nobodyさん2009/09/18(金) 23:58:31ID:???
もうYAML
0844nobodyさん2009/09/19(土) 00:19:38ID:???
ini くいことさらっと言うな
0845nobodyさん2009/09/19(土) 00:54:51ID:???
>>841
同じじゃないよ。
0846nobodyさん2009/09/19(土) 01:08:37ID:???
サーバへのコンテンツのデプロイってどうやってる？
俺はsubversionからupdateしてるけど
一般的な方法ってあるんだろうか
0847nobodyさん2009/09/19(土) 01:11:09ID:???
>>846
.svnもアップロードしてるの？
0848nobodyさん2009/09/19(土) 01:13:33ID:???
>>846
それが理想的だよな。

>>847
それが問題だよな。


公開ディレクトリ配下に.svnを置くのは少々不安。
0849nobodyさん2009/09/19(土) 01:22:43ID:???
ローカルでsvnチェックアウトしてrsync --exclude '.svn'する
0850nobodyさん2009/09/19(土) 01:24:57ID:???
httpd.confで.ファイル塞いでるからまず問題ないお
0851nobodyさん2009/09/19(土) 01:29:33ID:???
普通にSFTPでうｐ
0852nobodyさん2009/09/19(土) 01:35:26ID:???
>>851
それならrsyncの方が・・
0853nobodyさん2009/09/19(土) 02:54:38ID:???
ライブにいきなりシンクとだと高負荷のサイトはコードキャッシュが壊れたりするから気をつけよう。
0854nobodyさん2009/09/19(土) 06:17:24ID:???
Gitはどうなんかな
svnからわざわざ乗り換えるだけの価値あるの？
0855nobodyさん2009/09/19(土) 07:20:30ID:???
スレタイ読めよ
■ このスレッドは過去ログ倉庫に格納されています