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

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

レス数が950を超えています。1000を超えると書き込みができなくなります。
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/
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レスを超えてしまったため、新スレ立ておよび誘導前に落ちたようです
980レス付近になったら、次スレの準備をお願いいたしますで候

では引き続きフレームワークとは関係ない話題はほどほどにしつつ適当に語りましょう
0005nobodyさん2009/03/24(火) 14:42:00ID:???
いいかげんテンプレにピースFWも入れてあげて
0006nobodyさん2009/03/24(火) 15:21:25ID:vm768fgW
おせえよ
0007nobodyさん2009/03/24(火) 19:22:17ID:???
一応>>1乙。
つってもネタが無いのは変わらない
イチローがんばった。うん。
0008nobodyさん2009/03/26(木) 13:38:39ID:???
全然使えない感じだったzfも、いつの間にか機能充実してるね
form関係はよさげ
0009nobodyさん2009/03/26(木) 21:29:46ID:???
zf重いよ・・・
0010nobodyさん2009/03/26(木) 23:29:53ID:???
なんで重いん？
0011nobodyさん2009/03/27(金) 16:24:39ID:???
http://www.ibm.com/developerworks/jp/opensource/library/os-php-5.3new5/?ca=drs-jp
5.3でeregが非推奨になってるけど
pregだとマルチバイト文字列を簡単に扱えないじゃん
なめてんの？
0012nobodyさん2009/03/27(金) 16:27:43ID:???
と思ったらutf-8ならpregでも扱えるのか
にゃは
0013nobodyさん2009/03/27(金) 16:46:52ID:???
数年前からずっと続いているutf-8化への流れにあくまで逆らう人間は
それなりの苦労をすればいい、ってことだろう
0014nobodyさん2009/03/28(土) 01:24:33ID:zO5Id0L9
UTF-8の文字化けは、とりあえず「波ダッシュ問題」だけ気を付ければOKですか？
他にメジャーな文字化け現象はあるんでしょうか？

波ダッシュ問題 の検索結果 約 69,200 件
0015nobodyさん2009/03/28(土) 01:33:16ID:???
UTF-8 文字化け の検索結果 約 583,000 件
0016nobodyさん2009/03/28(土) 01:50:15ID:???
>>14
文字化けの原因を大別すると
１．文字セット間での変換時の変換テーブルの相互互換性の問題
２．データを処理する際のエンコーディングの取り違え
だと思うんだ。もちろん上記は複合する。

んで、波ダッシュ問題っての？その原因は１の方で、これは文字コードの変換さえしなければ起こらない。
例えば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　とシンフォニーで迷っています
名前からするとcakephpが一番良く思えるのですが
0018nobodyさん2009/03/28(土) 08:47:36ID:???
そんな人にはzf
0019nobodyさん2009/03/28(土) 10:04:04ID:???
>>17
両方のチュートリアルやってみたらいいと思う。
0020nobodyさん2009/03/29(日) 05:23:11ID:???
>>19
なるほど
cakephpからやってみますか
0021nobodyさん2009/03/31(火) 23:28:02ID:???
ちいたん使ってる人いる？
0022nobodyさん2009/04/11(土) 06:56:15ID:???
ちいたんとかいうの使うくらいなら自分でシンプルなFW書いた方がよくね？
0023nobodyさん2009/04/11(土) 12:47:07ID:???
ZF使えばよくね？
0024nobodyさん2009/04/11(土) 15:02:57ID:???
ZFは激重だという噂が・・
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:???
cakephpはphp4なのがちょっと
0032nobodyさん2009/04/15(水) 03:55:41ID:???
何か色々ツッコミたくなるレスだなw
0033nobodyさん2009/04/15(水) 09:36:15ID:???
>>28
コーディングスタイルはZend
0034nobodyさん2009/04/15(水) 22:14:59ID:???
いまからPHPフレームワークさわるんならYiiでイーんじゃね？
新しい分活発だろうし
0035nobodyさん2009/04/16(木) 15:19:10ID:???
自分の場合、使い方を覚えるのが一番早かったのがCI。
CIは解説本を１冊読んでチュートリアルのサンプルを作ったら、１週間程度で使い方が理解できた。

紆余曲折、結局WEBアプリの作成って、DBのラッパー作りだと納得した。
スカッフォルディングは使ってないけど、今ではFW（CI）のおかげでだいぶ生産性が上がり、楽ができるようになった。
とにかく何でもいいから１つFWをものにして、それを基準にして他と比較して、他が良ければ鞍替えすればいいと思う。

CIはシンプルなので、足りない機能があればZFから借用できる。
＝解説本にZFライブラリの利用方法が解説されていた。

CIの欠点は、CIがアメリカ製なので日本の携帯端末用ページを作るには不足が多いかもしれないということ？
CakePHPとSymfonyも一応解説本に目を通したが、覚えることが多そうだったので使わなかった。
CIよりも自分の開発規模・用途に適した、よさげなFWが登場したら、鞍替えすると思う。
0036nobodyさん2009/04/16(木) 19:38:44ID:PXJUiMOk
>>35
携帯不向きってのはどういう根拠？
ZendFrameworkとたいしてかわらんだろ？
0037nobodyさん2009/04/16(木) 20:11:42ID:???
>>36
携帯を判別するUAが外国のが用意されてるからだと思う。

0038nobodyさん2009/04/17(金) 00:39:00ID:???
そこだけPEAR?
0039nobodyさん2009/04/18(土) 00:44:08ID:???
携帯のUA判定ぐらいなら、自前で書いたほうが早い気がするけど。
0040nobodyさん2009/04/18(土) 00:46:18ID:???
>>39
PEAR使ってくれ。
ノウハウの蓄積の効用がわからんわけでもあるまいに。
また、その程度のノウハウを独占できる時代は終わってるんだぜｗ
0041nobodyさん2009/04/18(土) 00:52:03ID:???
>>39
早いだけでどうせ穴だらけなんだろｗ
0042nobodyさん2009/04/18(土) 01:55:12ID:???
>>40
＞その程度のノウハウを独占できる時代は終わってるんだぜｗ
まさしくその程度のノウハウだし、きっちり携帯切り分けるなら結局IPみたりするんだし、
やっぱり自前でやってもそんなに問題のあるコードが出てくるとはおもわなんだが。

>>41
ん〜、Net_UserAgent_Mobileに穴がない保証が見つからないし、あそこまでUAから
情報が必要になることもなさそうだしなぁ。

最近は、よさげな野良ライブラリ見つけたのでそれを参考に作ってみたりしたけど。
あと、インプレスが携帯電話の情報を無償提供とかやってるみたいだし、
結局PEARのライブラリの使いどころって、見えないなぁ。
0043402009/04/18(土) 02:02:09ID:???
PEARで一括りにする時点で、何かが違うと感じた。
それとはまた矛盾するかも知れない話ではあるが、少なくとも情報の集積という点で、
「よさげな野良ライブラリ」よりPEARに荷担したくなる自分もいる。

結局、あれだ。「自前で書いたほうが〜〜」に反発しただけなんだと思うわけだ。
>>42が気分を損ねて無いなら幸い。
0044402009/04/18(土) 02:04:47ID:???
自己レス
> PEARで一括りにする時点で、何かが違うと感じた。
これ先にやったの俺だな。
ごめん。読み流してやって下さい
0045422009/04/18(土) 02:32:07ID:???
>>40
特に気を損ねたりはしてないです。
「自前で書いたほうが〜〜」という件については、
まぁ、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:???
Request と Response という2つのクラスを作って、さらにこれをまとめるクラスを作りたい。
だけどいいクラス名が思いつかない。なにかいい名前プリーズ。

/// つくりたいクラス
class Http {
　var $request;
　var $response;
　function Http() {
　　$this->request = new Request();
　　$this->response = new Response();
　}
}
0047nobodyさん2009/04/18(土) 15:44:32ID:???
活発さならCakePHPがダントツ、次点でsymfonyかZend。
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

ほかは無いも同じだな。
0048nobodyさん2009/04/18(土) 15:59:56ID:???
>>46
分ける必要なくね？
0049nobodyさん2009/04/18(土) 16:01:56ID:???
違った逆だｗ
まとめる必要なくね？
0050nobodyさん2009/04/18(土) 16:17:18ID:???
>>46
ttp://www.phpfour.com/blog/2008/01/php-http-class/
（HTTPクラス）
とか、PEARのHTTP_Requestとか
0051nobodyさん2009/04/21(火) 05:05:52ID:TMA0XNZY
http://www.oracle.com/us/corporate/press/018363
Sunがオラクルに買収されてMySQL脂肪
すなわちPHP脂肪ｗｗｗ
0052nobodyさん2009/04/21(火) 07:38:02ID:???
>>51
こいつ来るだろうなぁと思ってたらやっぱり来たwww
0053nobodyさん2009/04/21(火) 15:54:29ID:???
しかしまさかMySQLがオラクルのものになる日が来るとはね・・
0054nobodyさん2009/04/21(火) 18:01:27ID:???
Javaも脂肪したからむしろPHP復活ｗｗｗ
0055nobodyさん2009/04/21(火) 22:20:27ID:8G0hNlN6
空気読まず貼りますね
http://www.cbook24.com/shop/ProductDetail.aspx?sku=9784798022574&CD=F1000049&WKCD=F1000037
0056nobodyさん2009/04/22(水) 23:08:42ID:???
Zendも買っちゃえよｗ
0057nobodyさん2009/04/22(水) 23:50:12ID:6FnKU0By
PHPにフレームワーク要るか？少なくとも自家製テンプレートは本当に邪魔なだけだろ。
0058nobodyさん2009/04/23(木) 12:00:54ID:???
自家製テンプレートってなに？
0059nobodyさん2009/04/23(木) 22:39:36ID:???
Yiiイイヨー
0060nobodyさん2009/04/26(日) 21:10:58ID:???
Yii よくねえよwwwwwwwwwwwww
0061nobodyさん2009/04/27(月) 10:17:04ID:???
Yiiって速いらしいじゃん、ほんと？
0062nobodyさん2009/04/27(月) 12:51:24ID:???
>>57
同意。

・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:???
acom
0065nobodyさん2009/04/27(月) 15:02:38ID:???
>>62
テンプレートエンジンの思想は、PHP構文を置き換える目的では無いよ。

・デザイナに与える権限を最小限にする(PHPを直に触らせない)
・結果的にコード記述方法が統一される
・PHP以外の言語からも再利用出来る
・キャッシングや独自タグなどの拡張が楽
・可読性が生PHPと比べて高い

等メリットはあるし、ケースバイケースだね。
0066nobodyさん2009/04/28(火) 18:10:44ID:???
>>63
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:???
WEBサイトのシステムは、MVCに分割すれば、それだけでも保守性の確保は十分だと思う。
VのところでSmarty等のテンプレートエンジンを使うか、使わないか？

HTMLの中にPHPのコードを埋め込めるから、生PHPそれ自体が一つのテンプレートエンジンとして使える。
生PHPよりも高機能なPHP製テンプレートエンジンってないから、生PHPは便利ですよ。

以前はSmarty使っていたけど、今は生PHPに戻りました＾＾
テンプレートエンジンを使う人には、それなりに理由があるだろうから、別に否定はしないけど。
0069nobodyさん2009/04/29(水) 16:03:31ID:???
> 生PHPよりも高機能なPHP製テンプレートエンジンってないから、生PHPは便利ですよ。

lol
0070nobodyさん2009/04/29(水) 17:32:01ID:???
これはひどい
0071nobodyさん2009/04/29(水) 18:06:52ID:???
生PHPに自動escapeがあれば検討に値するんだがな
0072nobodyさん2009/05/02(土) 01:51:14ID:???
>>71
そのくらい作れよ
0073nobodyさん2009/05/02(土) 18:55:40ID:???
>>71
FW側でエスケープできないの？
テンプレートでエスケープするの？
0074nobodyさん2009/05/04(月) 19:33:15ID:???
viewにオブジェクトなんか持って行くようなつくりだと、FW側でのエスケープは難しい、というか煩雑だろうな。
テンプレートの記述でちょろっと書いたらescape（または非escape）ってのが今のところベターな気がする。

生のPHPで E() とかグローバル関数を作って使ってもいいんだろうが、一気にきちゃなくなりそうだ。
0075nobodyさん2009/05/05(火) 15:57:12ID:???
>>71
例えば、

<? ?> #=> <?php ?>
<?= ?> #=> <?php echo ?>

に加えて、

<?== ?> #=> <?php echo エスケープ処理(); ?> （処理内容はPHP_INI_ALLで設定可能）

みたいなタグを追加する、とか？
こんな感じで実装されれば、ショートタグ全盛時代がくるだろうな。
0076nobodyさん2009/05/05(火) 17:54:07ID:???
そこまでして数文字節約できて本当に嬉しいの
0077nobodyさん2009/05/05(火) 18:15:20ID:???
>>76

<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:???
>>75
どうせphp本体に手を入れるのなら、「出力は全て自動エスケープされる」モードを作った方がよくね。

俺は今、テンプレートに変数を割り当てた時点(FW側)で全てエスケープされるようにして、
変数にHTMLタグを割り当てた場合、テンプレート側でデコードするようにしている。
但し、>>74の言うようにオブジェクトは除いて別扱いせざるを得ない。
<?php echo や <?= なら自動エスケープ。<?== ならそのままってなほうがいい。
0080nobodyさん2009/05/05(火) 19:13:28ID:???
>>79
理屈はわかるけど、あくまでも、特殊処理をする方を特殊な書き方にした方がいいと思うな。
magic_quotesの悪い前例もあることだし。
それにそうしないと、例えばファイルに書き出すときにはモードをオフに、とかしなきゃいけなくなる。

まあおれの場合は実装の絡まない妄想だが。
0081nobodyさん2009/05/05(火) 19:46:40ID:???
htmlのレンダリングにおいてはescapeしないほうが特殊な処理だし、
安全性を考えたらdefaultでescapeのほうがいいと思うけどね。
0082792009/05/05(火) 20:32:40ID:???
>>80
ちょっと書き方が悪かった。
あくまでFWのview出力において全て自動エスケープ。

たとえば $view->display()としたときにdisplayメソッド内で自動エスケープをONにして
テンプレートスクリプト(生PHP)を処理していく感じ。
0083nobodyさん2009/05/06(水) 03:44:19ID:???
defaultでescapeとかまともに考えたらありえない。
magic_quotes以上のゆとり思考だろ・・・

<?== ?> タグ程度なら、自前で実装出来そうだし、
用意された機能で実装すりゃいいんじゃねーの？

それをテンプレートエンジンと呼ぶかどうかは別にして
0084nobodyさん2009/05/06(水) 03:50:45ID:???
何か問題でも?
0085nobodyさん2009/05/06(水) 07:05:34ID:???
>>83
なんでdefaultでescapeがありえないの？
いや純粋に・・・ゆとりですまそ。
0086nobodyさん2009/05/06(水) 11:41:38ID:???
>>83
前段二行は、まあPHPとはそういう言語（？）だと。
他にもmb_stringの自動変換とかsafe_modeとか、もろもろの余計なお世話で
成り立ってるんだし、他の機能と比べればHTMLエスケープの標準オプション化くらい
なんてことはない。

ただ、エスケープの為だけにタグを"スクリプトでの"実装はあり得ないなｗ
後半はそういう意図に読めるが、それだけのテンプレートエンジンなんて筋が悪すぎる。
PHP拡張としてパーサレベルで実装してあれば便利かな、ってものだと思う。
0087nobodyさん2009/05/06(水) 12:10:05ID:???
だからsmarty使えばいいじゃん
{$var}で解決よ
0088nobodyさん2009/05/06(水) 12:22:12ID:???
>>87
>>68,71 （とそのちょっと前から）の流れだってば。
そりゃ現実的にはみんないろいろやってるだろうけど、
仮定の話はそんなに面白くないかな？
0089nobodyさん2009/05/06(水) 12:54:21ID:???
じゃSmarty使わない理由をまとめてくれ
0090nobodyさん2009/05/06(水) 13:24:40ID:???
>>89
すごく消極的だが、前提ライブラリは少なければ少ない方がいい、とか。
Smarty以外にもテンプレートエンジンはあるし、どれも標準にはなり得ない。
最近のFWでもテンプレートエンジンを必須の前提にしていないものが大半だが、
その理由と同じってのでどうだろう。

俺は使えればSmarty使う派だから想像だけど。
0091nobodyさん2009/05/06(水) 17:24:24ID:???
数年仕事で使っているが、magic_quotesも、mb_stringの自動変換も、ショートタグも、大半の環境ではオフにされているんだが・・・
実装出来る手段が用意されていて、特別困るものでも無いのに標準機能として盛り込んでしまうと、
裏側の処理を理解していないゆとりPGが泥沼にはまるのが目に見えるわ・・・

そもそもPHPはHTMLを出力するためだけのモノでも無いし、
HTML出力に関しても100%エスケープが必要なものでもない。
0092nobodyさん2009/05/06(水) 19:26:56ID:???
>>91
> 大半の環境ではオフにされているんだが・・・

これらがデフォルトになったのはごく最近の話って認識なんだが。
register_globalsだけが少し早かったと。
実際今までだってここら辺に嵌るのがある意味通過儀礼のようなもんだっただろｗ

んで、逆にそういう知識が常識として定着した現状なら、いろんな機能がついてても
それほど問題にもなるまいという風に考えてしまうな
0093nobodyさん2009/05/07(木) 13:41:10ID:???
デフォルトでエスケープするのは、いろんなテンプレートエンジンでもそういう機能がある。PHP自体にあってもいいと思う。<?=を別のマクロにすればいいんだろ。エスケープし損なうぐらいなら、余計なエスケープしてしまった方が安全だから。
0094nobodyさん2009/05/08(金) 22:46:49ID:???
つうか、まだ懲りずにSmartyを使っているやつがいるんだね。あおりぬきで驚かされる。
0095nobodyさん2009/05/08(金) 23:30:04ID:???
php5.3RC2がでたようだけど、5.3になってから
これからのフレームワークは具体的にどう変化するの？
0096nobodyさん2009/05/08(金) 23:34:42ID:???
namespaceを使うものが出てくるくらいか？
それだけではそんなに変わりそうな気もしない
何より、フレームワークはあんまりすぐには新バージョンに追随しないと思う
0097nobodyさん2009/05/08(金) 23:54:56ID:???
late static bindingsの導入で静的メソッド主体のユーティリティクラスを
継承して拡張するのは楽になりそう。
0098nobodyさん2009/05/09(土) 00:09:06ID:???
>>97
これか
ttp://jp2.php.net/lsb

self::、parent:: に static:: が加わるってことでいいのかな。
しかしこれを読んだだけでは、parent::のstatic::バージョンも欲しくなりそう。
無いって事は、普通はいらないってことなのだろうか。
0099nobodyさん2009/05/12(火) 06:50:24ID:V/2qAUy/
singletonオブジェクトの初期化パラメータってどう渡す？
・最初のgetInstance時に初期化パラメータを渡す
・staticなsetXXメソッドを実装して初期値を渡す
選択肢としてはこんくらい？
0100nobodyさん2009/05/12(火) 08:28:25ID:???
インスタンス取ってからすべきでは？
0101nobodyさん2009/05/12(火) 08:45:51ID:???
なるほど
コンストラクタでの初期化にこだわってたけど
その方がキレイかも・・ありがとう
0102nobodyさん2009/05/12(火) 13:04:35ID:WVFMmzYl
そろそろ、yiiの日本語書籍とか出ても言い頃じゃないの？
0103nobodyさん2009/05/12(火) 21:23:25ID:???
公式とyiidocで間に合ってる気はする
0104nobodyさん2009/05/13(水) 08:32:44ID:???
>>94
なんに懲りるの
0105nobodyさん2009/05/15(金) 20:00:09ID:wv3qSkZj
フレームワーク本出ますよ。ご丁寧にCodeIgniterまで。
http://www.shuwasystem.co.jp/products/7980html/2277.html
0106nobodyさん2009/05/15(金) 21:55:29ID:???
掌田津耶乃ってまだ生きてたんだな
0107nobodyさん2009/05/16(土) 02:33:23ID:???
PHPを一通り使えるようになった人向けのPHPフレームワークの入門書です。
フレームワークは、Webアプリケーションの全体構造の仕組みを提供し、
プログラマが書くべきコード量を減らしてくれます。
特に複雑で大規模なアプリケーションになるほど効果は大きくなります。

本書では、注目のPHPフレームワーク4種
（CakePHP/Zend Framework/symfony/Codelgniter）の基本を解説。
MVC（モデル、ビュー、コントローラー）アーキテクチャの基礎のほか、
データベース接続やバリデーションの方法や各フレームワークの特徴がわかりますので、
自分の開発するWebアプリケーションに必要なフレームワークを比較・選択することができます。

各フレームワークを収録したCD-ROM付き。

---
注目…？
0108nobodyさん2009/05/16(土) 02:47:04ID:???
>>99
setXXとあんまかわんないけどfactoryメソッド作って、コンストラクタ叩いてstaticなsingleton変数に突っ込めば？
0109nobodyさん2009/05/16(土) 22:53:53ID:???
PHPではグローバル変数を使え。PHPにシングルトンなんて全く実利が無い。IISやJavaなら実利がある。使いたければPHP止めろ。
0110nobodyさん2009/05/17(日) 00:54:10ID:???
>>109
PHP5でコンストラクタもプライベートに出来るようになったし、
staticなメンバ変数も保持できるようになったわけだし、
実利がまったくないってことないんじゃない？

ライブラリ作った場合にライブラリ側で
そのオブジェクトは常に一つしか作成されないのかどうかを出来るっていうのも
ポイントだとおもうけど。
0111nobodyさん2009/05/17(日) 01:56:03ID:???
リクエストをまたいでメモリ上に存在しないオブジェクトに
Singletonは必要ないというのも了見が狭いなあ。
>>110みたいにコーディング上の利点は十分にあるのに。
0112nobodyさん2009/05/17(日) 08:42:30ID:???
>IISやJavaなら実利がある
>PHPではグローバル変数を使え。

の二言で全て台無し。

コンストラクタをプライベートにするもよし、
コンストラクタ内でstaticインスタンスの存在をチェックして、例外を投げるとかで実装上さほど問題無い。
（マジックメソッド系も実装必要ね）
0113nobodyさん2009/05/17(日) 15:17:13ID:???
ま、あんまり意味ないのは確か。
0114nobodyさん2009/05/17(日) 16:11:16ID:???
PHP歴4年。
グローバル変数ほとんど使った事無い
0115nobodyさん2009/05/17(日) 17:37:11ID:???
クラスのプロパティ使ってアクセスするより、
グローバル変数使ってアクセスしたほうが速かったような気がするんだが、どうなんだっけ。
0116名無し募集中。。。2009/05/17(日) 17:50:22ID:wjR/zk6c
仮にそうだとしてもバグの修正は10倍遅くなるぜ
0117nobodyさん2009/05/17(日) 18:47:40ID:???
よく言われてるのはグローバル変数じゃなくてローカル変数ね。
プロパティよりローカル変数にアクセスするほうが速いのは確かなんだけど
マイクロベンチマークで「こんなに違うんですよ」と言えるだけで
実際のアプリケーションの動作からすると誤差の範囲でしかない。
0118nobodyさん2009/05/17(日) 22:42:55ID:???
$_SESSIONや$_REQUEST、みんな使ってるだろ。オブジェクトにすると面倒だけど、ハッシュならprint_rで一発で目視出来る。
0119nobodyさん2009/05/18(月) 00:28:50ID:???
objectにキャストすればおｋ
0120名無し募集中。。。2009/05/18(月) 01:30:21ID:wP2DRNT9
>>118
みんなが言ってるグローバル変数ってそのことじゃないと思うぞ
0121nobodyさん2009/05/18(月) 02:42:31ID:???
わらたｗ

つか、グローバル変数云々の問題って
複数人がかかわるようなもの作ったり、いろんなものを組み合わせて使ったり
そういうときに名前(変数名)がぶつかって不具合でる可能性がないようにするため
クラスぷろぱてーやらローカル変数やら使おうって話でしょ

すべてを一人で把握するような規模でかつ独立してるもんを想定してるんなら
グローバルだろうが問題ないとはおもうよ。わしはやらんが

だいたいそんなしょっぱい規模のものだったらフレームワークとは無縁ｗ
0122nobodyさん2009/05/18(月) 02:52:59ID:???
そんなことみんな分かってるんじゃないかな？かな？
0123nobodyさん2009/05/18(月) 08:56:15ID:???
先頭が_ですべて大文字で記述するってルールにすればぶつかるわけがない。PHP自体がそういうグローバル変数を初めから持ってるんだから。
0124nobodyさん2009/05/18(月) 09:25:31ID:???
意味が分からない
「ぶつかるわけがない」と思ってる奴が他にもいたらぶつかるだろ
0125nobodyさん2009/05/18(月) 11:03:40ID:???
グローバルとスーパーグローバルは分けて語ろうな
0126nobodyさん2009/05/18(月) 11:08:25ID:???
問題は$GLOBALSというスーパーグローバル変数があってだな。
でも、むしろこっち使ってもらう方が何かといいかｗ
0127nobodyさん2009/05/18(月) 13:45:20ID:???
グローバル変数だらけのソースを
保守する人のことも考えて。
0128nobodyさん2009/05/18(月) 15:51:21ID:???
関数やメソッド内で毎回global 宣言するんすかｗ
0129nobodyさん2009/05/18(月) 21:30:16ID:???
ｈ
0130nobodyさん2009/05/19(火) 00:43:21ID:???
それなりの規模でグローバル変数を多様しないといけないものを作ってしまう時点で
技量不足知識不足と宣言してるも同義
まともなPGなら意図的にそんなことやる意味ないことくらい理解してる
0131nobodyさん2009/05/19(火) 04:39:13ID:???
グローバル変数をなくしたら、今度は大量の引数を要求する関数がうじゃうじゃと(ry
0132nobodyさん2009/05/19(火) 04:43:36ID:???
それは密結合すぎ
0133nobodyさん2009/05/19(火) 08:24:34ID:???
>>131
配列、オブジェクト、クラスを引数として渡せば解決ですね。
0134nobodyさん2009/05/19(火) 09:05:36ID:???
メンバ変数が大量にあるデブクラス
0135nobodyさん2009/05/19(火) 10:35:21ID:???
引数の多い関数/メソッドに関しては

　クラス引数≧配列引数≧普通の引数＞＞＞グローバル変数

で書くべきだな。
グローバル変数を引数として扱うメリットって何なの？
デフォルト値とか型チェックとか面倒な事しか思い浮かばないんだが・・・
0136nobodyさん2009/05/19(火) 12:26:18ID:???
横断的な変数やオブジェクトの格納じゃないか

ログとか全体的な設定とか
0137nobodyさん2009/05/19(火) 12:40:47ID:???
どうしてもグローバル変数を使いたかったら、$GLOBALSを使えばいいのに。
それなら却って、クラス変数やシングルトンなんかでごにょごにょするよりは
PHPのうまみがあるかも。

すくなくともglobal 変数名よりは反感も少ないだろうし、使ってるうちに少しは
多用に疑問も感じるはず。
0138nobodyさん2009/05/19(火) 13:12:52ID:???
>>135
ムシャクシャしてグローバル変数を使った。
動けば何でも良かった。
0139nobodyさん2009/05/19(火) 13:50:36ID:???
$_なんちゃらのスーパーグローバルなやつらみたいにホイホイ使えるからいいんだよｗ
というか、グローバル禁止ならそいつらもオブジェクトにでも詰め込んでそれを引数にして関数を呼べよと。
0140nobodyさん2009/05/19(火) 14:33:19ID:???
で、グローバル変数を使ってる or 推奨しているフレームワークってあるの？

グローバル定数の代替え手段を理解していない素人が喚いているだけ？
0141nobodyさん2009/05/19(火) 15:09:14ID:???
>>140
フレームワークの話題でなければスレ違い、って意図だと解釈しておく。
配布されているような汎用フレームワークでは、さすがにグローバル変数は使えないだろう。

ただ、そこら辺で実稼働してるような俺流フレームワークなどの規模や必要性なら、
ガチで原理主義なOOPコーディング（っぽいもの）なんかより、読みやすく
手入れしやすいグローバル変数の使い方もできるだろうし、されてるかもね。
要は使い方だって。
0142nobodyさん2009/05/19(火) 17:05:54ID:???
>ガチで原理主義なOOPコーディング（っぽいもの）なんかより、読みやすく
>手入れしやすいグローバル変数の使い方もできるだろうし、されてるかもね。

全く想像つかんｗ

複数人で開発した際に変数名の競合を防げなかったり、
引数としての型チェックやデフォルト値が設定出来ないわけだが…

コーディング規約を徹底管理すれば何とかなるが、
後者はテストを含め、実装には無駄な手間がかかるだろう。

ロジックや変数の局所化はOOP以前の話だと思う。
0143nobodyさん2009/05/19(火) 17:45:17ID:???
>>142
だから、$_POSTやら$_GETやら$_COOKIEにどこからでも代入出来る時点で、
変数の局所化なんて崩れてるって。
# こいつらを最初にいちいちコピーして空っぽにするのが最近は普通なのかな？

なんで「グローバル変数を使う」 ＝ 「無制限に読み書きする」に直結するんだろう。
読むだけなら何の問題もないって。

規約って言ったって、（決まってる初期処理以外で）$GLOBALSに代入する奴は死刑、
ってだけでいいじゃないか。あくまで、$GLOBALSのみ使うっていう前提だけど。

俺はまあまず使わんけど、便利そうな使い方は想像できなくもないよ。
01441432009/05/19(火) 17:59:28ID:???
って書いて、なんかわかってきた。
自分がそう思うのは、関数（メソッド）の外でスクリプトを書くって事がないからか。
もう全部、下敷きのディスパッチャがある環境でしかスクリプト書かないし、
トップレベルのスコープで書かれた部分って数枚で、増えない。

もしトップレベルでいろいろ書く必要があるなら、グローバル変数に
代入しないわけにはいかないか。
そうなると、さすがにいきなりグローバル変数の参照は怖くてできんわな。

まあどっちにしろ、局所化できるかどうかの話だけだとは思う。
0145nobodyさん2009/05/19(火) 18:04:18ID:???
>だから、$_POSTやら$_GETやら$_COOKIEにどこからでも代入出来る時点で、
>変数の局所化なんて崩れてるって。

言語レベルで周知されている値と、ユーザーグローバル変数を同列には語れないかと。
(素人でも $_POST を上書きしちゃマズイって事くらいは理解しているだろう)
一部の局所化が既に崩れているから、さらに崩して良いという考えかい？


>なんで「グローバル変数を使う」 ＝ 「無制限に読み書きする」に直結するんだろう。

制限事項を規約で作るくらいなら、定数化なりクラス化するのが普通じゃないかね。
言語レベルで制限御出来る機構が提供されているのに、それを使わない理由がわからない。
0146nobodyさん2009/05/19(火) 20:12:14ID:???
全然関係ないけど、CodeIgniterは$_GETを空にするよね。
全然関係ないけどね。
0147nobodyさん2009/05/19(火) 21:13:04ID:???
結局自分がやってるお仕事のせまい範囲でかたってる人がいただけだったというオチ
しかもフレームワークそんな関係ない
0148nobodyさん2009/05/19(火) 21:39:39ID:???
いや、フレームワーク使ってるからこそ、グローバル変数容認論が出るんじゃないかと
そういう意味では関係ある、ような無いような
0149nobodyさん2009/05/19(火) 21:54:40ID:???
PEARは使ってるな
0150nobodyさん2009/05/20(水) 00:06:53ID:???
まぁ、使いまわしをする前提で作成したライブラリにグローバル変数使うのは避けたいかな。
0151nobodyさん2009/05/20(水) 02:14:41ID:???
変なオブジェクト（ビューから呼べないとか）使わされるより、$_REQUESTや$_SESSION使った方がいい。
0152名無し募集中。。。2009/05/20(水) 02:19:49ID:by98XaTN
なんで渡されるのが変なオブジェクト前提なのか解らんが
0153nobodyさん2009/05/20(水) 02:35:48ID:???
Viewからrequestやsessionなんて呼ばないだろ。
0154nobodyさん2009/05/20(水) 07:21:54ID:???
>>151
もう一度MVCを勉強した方がよくね？
0155nobodyさん2009/05/20(水) 13:20:19ID:???
数年使った事ないと書いたモノだが...

サービスロケーターを実現するために、他のクラスに依存しないということにおいてグローバル変数は有用だと思う。
PEARが使ってるのもそういう理由じゃないかな。
スコープがグローバルなのはクラス名も同じ。名前衝突解決法も同じで良いと思うしPEARもそうしてる。
0156nobodyさん2009/05/20(水) 13:50:50ID:???
クラスだと名前衝突が起きた場合にPHP側が警告してくれる。
グローバル変数だと知らぬ内に値が書き換えられる可能性がある。

この差は大きいと思うので、極力クラス化している。
0157nobodyさん2009/05/20(水) 16:36:09ID:???
クラスだと関連する定数持たせたりできるしな
グローバル変数なんて石ころみたいなもん
0158nobodyさん2009/05/20(水) 20:18:38ID:???
PHP標準のセッション管理やクエリーパラメーター管理は、連想配列のグローバル変数。皆これを使ってる。それで十分だから。
0159nobodyさん2009/05/20(水) 20:24:27ID:???
もしPHPのデベロッパーがセッション管理をオブジェクトにすることが有意と思ってるなら、組み込みクラスを実装してるだろう。
が、そんなことしてもメリットは薄いし、初心者に優しいPHPの良さを消すことになる。ので、PHPのセッション管理は連想配列のまま。
0160nobodyさん2009/05/20(水) 23:22:06ID:???
だからこそフレームワークがあるわけだが。
0161nobodyさん2009/05/20(水) 23:37:13ID:???
>>159
クラスオブジェクト作るときってただ単純にセッションを管理したいってだけで作るわけじゃないだろ。
ある一定の目的が定義されてて、その定義にあわせて管理することを考えたときに
一つの意味の集合であるクラスを作るのであって。
PHPのデベロッパーはセッション管理をすることの意味なんて凄く広義的に考えて設定してるから、
グローバルな連想配列になってんじゃないのか。
0162nobodyさん2009/05/20(水) 23:39:50ID:???
そもそも、PHPのスーパーグローバルを否定してる奴はいなくね？
ユーザが勝手に作るグローバル変数をスーパーグローバル変数と同列で語るのがおかしいわけで…
0163nobodyさん2009/05/21(木) 00:01:09ID:???
「ユーザが勝手に作るグローバル変数」が問題になるのは、
結局、仕様書だの会社で規定されてる命名規則だの何だのとかきちんとしてないのに
>>109のようなことをつぶやいて>>127のような人を量産する場合なんだろ。

結局オープンソースだとか使いまわし前提のライブラリだのでそんなの使ってると後で使う人が困ったことになるってだけで。
0164nobodyさん2009/05/21(木) 00:26:39ID:???
スーパーグローバル変数をグローバル変数と勘違いしている輩に振り回されるだけじゃない？
0165nobodyさん2009/05/21(木) 01:01:42ID:???
グローバル変数主張してる人はメリットばかりでデメリットをあげないからなぁ、
単なる素人発言にしか見えないんだわ。

実際になんらかのフレームワークを使った上で、
グローバル変数のメリットデメリットを比較してみてくれよ。
0166nobodyさん2009/05/21(木) 02:12:20ID:???
定数はどうなの？
定数もグローバル(define)じゃなくてクラス定数にしてんの？
0167nobodyさん2009/05/21(木) 02:26:54ID:???
defineは使わん
0168nobodyさん2009/05/21(木) 09:09:50ID:???
定数と変数じゃ用途が大分用途が違うしなぁ
使ったとしても最低限のフラグ程度にしか使わないし
DEBUG_MODE とか、そんな感じのやつ。接頭子もつけてる。

クラスに関する定数は、当然クラス定数にしているよ。
0169nobodyさん2009/05/21(木) 09:46:04ID:???
作りすぎなければ良いだけのこと。まあ、たくさん作ったとしても、どうせリクエストの度に消滅するんだから、それほど気にすることもないが。
0170nobodyさん2009/05/21(木) 10:17:04ID:???
リクエスト内で競合する可能性が問題視されてるのでは？
0171nobodyさん2009/05/21(木) 10:34:56ID:HWozpBcz
>>109に釣られ過ぎだろ
いや、それ以下か。シングルトンいらんって話が、引数を渡すのにとか名前がぶつかるからって話にダウングレードしてるし
0172nobodyさん2009/05/21(木) 13:53:57ID:???
定数を多重定義したらエラーが表示される。
0173nobodyさん2009/05/21(木) 14:55:07ID:P779ZgB3
最近、はてな界隈ではCakePHPとSymfonyの話ばっかりだよ。
あいつら、ZendFrameworkやCodeIgniterの事なんて気にもしてないよ。
0174nobodyさん2009/05/21(木) 15:00:58ID:???
>>173
たんなる感だけど、日本で流行らないのは名前の文字数のせいだと思ってるｗ
0175nobodyさん2009/05/21(木) 16:23:26ID:P779ZgB3
>>174
マジでwww！！？
0176nobodyさん2009/05/21(木) 16:24:30ID:???
PerlよりRubyよりもちろんJavaよりも短いPHPやっぱり最強だな
0177nobodyさん2009/05/21(木) 18:32:40ID:???
比較的大きな案件ならCodeigniterなんて論外だろ。
0178nobodyさん2009/05/21(木) 18:41:02ID:???
なんで？
だいたい、どれくらいで「大きな案件」よ
はてな住人はそんなにみんな大きな案件ばっかりやってるのか？
0179nobodyさん2009/05/21(木) 19:18:31ID:???
いざって時に情報や技術者が少ないと困るからじゃね？
Codeigniter出来る人を求人してもいなさそうなイメージ…。
0180nobodyさん2009/05/21(木) 22:34:08ID:P779ZgB3
phaだって、CakePHP使ってるんだぞ！
0181nobodyさん2009/05/21(木) 22:51:25ID:???
CodeIgniter(笑)
0182nobodyさん2009/05/22(金) 00:15:18ID:???
うまく説明できないけど、CodeIgniterはないと思うに一票。
0183nobodyさん2009/05/22(金) 00:22:03ID:???
CodeIgniterは、コア部分とかをオーバーライドして簡単に修正出来るのと
実際公式サイトに書いてあるように習得が楽なので、ないこたないと思うけど？

バリデータがしょぼかったから別の使ってるけど。

まぁ、一人で適当にアプリ作るには割りとちょうどいいかな。
階層も薄いからどこでどう動いてるかとかも把握しやすいし。
0184名無し募集中。。。2009/05/22(金) 00:30:33ID:f3nFju+F
グループ開発になるとZend,Symfony,Cake,Ethnaくらいしか選択肢ないよ
それ以外は経験者集められない
0185nobodyさん2009/05/22(金) 00:55:57ID:RzyQ8gRW
>>184
ありすぎて、問題だなｗ
0186nobodyさん2009/05/22(金) 01:13:02ID:???
>>174
ありえそうな気がしてくるｗ
CodeIgniterとかよめねぇｗｗｗｗみたいなのいっぱいいそうｗｗｗｗｗ

こでいぐぬぃてぇあ
0187nobodyさん2009/05/22(金) 01:35:28ID:???
>>178
比較的大きな案件といっても中規模レベルのことで、
それ以下の更に以下ぐらいにCodeigniterの選択肢があるわけで。
0188nobodyさん2009/05/22(金) 01:35:53ID:???
なんでコードまで読めなくなるんだよｗ
0189nobodyさん2009/05/22(金) 02:03:28ID:???
なんだかんだでZendブランドは強い。
0190nobodyさん2009/05/22(金) 09:57:18ID:???
>>186
せめて名前が、Code Igniter だったらまだマシだったのかｗ
0191nobodyさん2009/05/22(金) 12:25:09ID:RzyQ8gRW
yiiとかどうなの？
0192nobodyさん2009/05/22(金) 14:29:39ID:???
>>191
文字数的にはヒットの予感ｗ

パフォーマンス的には結構よさそうだけど、使い難そうだね。
日本に限らず流行らないほうに1票。
0193nobodyさん2009/05/22(金) 15:46:56ID:???
なるほど、じゃぁ文字数的にはやっぱりCが最強なんだな。
0194nobodyさん2009/05/23(土) 09:51:40ID:???
Cって検索するとき困る
0195nobodyさん2009/05/23(土) 10:02:39ID:???
付き合うならDぐらいは欲しいな
0196nobodyさん2009/05/23(土) 11:28:31ID:sw/qjhoP
Dと付き合ってるけど毎年性格が豹変するから疲れる
0197nobodyさん2009/05/23(土) 19:45:31ID:???
そこで颯爽とR登場。マニアックな魅力にみんなイチコロ（死語）
0198nobodyさん2009/05/24(日) 00:13:51ID:???
エラー表示が優れてるフレームワークはどれ?
0199nobodyさん2009/05/24(日) 00:17:05ID:???
php
0200nobodyさん2009/05/24(日) 01:25:18ID:UrsSuZGN
>>198
Cakeじゃね？DBのクエリーを見れるじゃん。
0201nobodyさん2009/05/24(日) 08:19:09ID:???
クエリー出るのはいいね
0202nobodyさん2009/05/24(日) 09:51:07ID:???
SQLクエリのエラー表示、ってだけで見るのもどうかと
PHP5に特化して統一されたエラーハンドリングができる方がフレームワークとしてはいいかもよ。

SQLのエラー（例外）をキャッチできればクエリ出すことも簡単だろうし。
ZFやらKohanaとかもいいんでね？面倒なのでやってないけど。
0203nobodyさん2009/05/24(日) 10:02:26ID:???
その面倒がだめなんでしょ
0204nobodyさん2009/05/24(日) 10:10:00ID:???
うん。なるほど。納得
0205nobodyさん2009/05/24(日) 11:18:37ID:???
ZFはDBアダプタにプロファイラ設定するだけで、
クエリから実行時間まで全てログれる件。

表向きに簡単！便利！と売るより、
プログラマにとって地味に嬉しい機能を全面に出すフレームワークは無いものかね
0206nobodyさん2009/05/25(月) 00:26:34ID:???
>>205
地味に嬉しい機能って何?
0207nobodyさん2009/05/25(月) 00:28:25ID:n6zT/Oby
ZendもCakeもSymfonyも表向きだけじゃなくてプログラマ向けに便利だと思うけど
0208nobodyさん2009/05/25(月) 00:44:44ID:3dtn4t5a
>>206
http://framework.zend.com/manual/ja/zend.db.profiler.html
0209nobodyさん2009/05/25(月) 03:07:58ID:???
> getQuery() は、クエリの SQL テキストを返します。
パラメータつきのプリペアドステートメントの場合、 クエリがプリペアされた時点のテキストを返します。
つまり、プレースホルダを含んだままの形式ということです。
実行時に置き換えられた値を知ることはできません。

orz
0210nobodyさん2009/05/25(月) 05:21:49ID:???
Perlの場合、フレームワークとか関係無しに、DBI経由でSQLをダンプできる。
0211nobodyさん2009/05/25(月) 05:32:16ID:n6zT/Oby
それはPHPでもなんでも出来るので
0212nobodyさん2009/05/25(月) 07:03:40ID:???
perlすごいな
PHPは捨てることになします
ありがとうございました
0213nobodyさん2009/05/25(月) 07:28:25ID:???
さようなら
文盲はもう帰ってこなくていいよ
0214nobodyさん2009/05/25(月) 09:11:31ID:???
PHPの組み込みDB関数にSQLのダンプ機能ってあるのか？
0215nobodyさん2009/05/25(月) 09:44:24ID:???
あるんじゃない？必要ないから使ったことはないけど。
0216nobodyさん2009/05/25(月) 11:30:40ID:???
どうやるの？php.iniで設定するとか、コネクション張るときに引数に渡すとか
0217nobodyさん2009/05/25(月) 11:37:50ID:???
ひょっとしてDBのログをtailfで見ている俺は勝ち組?
0218nobodyさん2009/05/25(月) 12:31:52ID:???
>>200
それsymfonyからパクった機能じゃん
0219nobodyさん2009/05/29(金) 04:53:50ID:???
>>217
勝ち負けは知らんが、確立された方法があるなら素敵なことだと思う。
開発中 tail -f をDBログに対して常に可能な状態なら、それは一種のフレームだもん。
0220nobodyさん2009/06/08(月) 00:42:53ID:???
静かだな。
なんかネタない〜？
0221nobodyさん2009/06/09(火) 00:03:04ID:???
アンケートでもするかー

1 今使用してるフレームワーク
2 使用した事のあるフレームワーク
3 それぞれの寸評または10点満天でのスコア
4 欲しい機能

どぞ
0222名無し募集中。。。2009/06/09(火) 00:24:43ID:JTieN+g5
1 今使用してるフレームワーク
個人ではCakePHPとZendFramework
仕事で他人が作ったSymfonyのシステムもいじる
2 使用した事のあるフレームワーク
Ethna
Mojavi
Maple
CakePHP
ZendFramework
Symfony
3 それぞれの寸評または10点満天でのスコア
Ethna 8点 かなり良いけど今使うには古い
Maple,Mojavi 初期構築やってないんであんま記憶ない
CakePHP 9点 初期構築なら一番開発が楽
ZendFramework 7点 自由すぎで楽はできない
Symfony 5点 これしか知らなかったらこれでいいけど、他知ってると荒が見えてしまう
4 欲しい機能
日本のガラパゴス携帯に簡単に対応して欲しい
無理だろうけど
0223nobodyさん2009/06/09(火) 01:57:18ID:???
MOONGIFT: ? Sinatraを真似たPHP用軽量フレームワーク「Fitzgerald」
http://www.moongift.jp/2009/06/fitzgerald/

簡単なURLマッピング、シンプルなレスポンス。どれをとっても簡単だ。
そんなSinatraを真似たPHP用フレームワークがFitzgeraldだ。

0224nobodyさん2009/06/09(火) 09:20:00ID:???
>>222
沢山つかってるねー
Symfonyってそんなんなんだ...
0225nobodyさん2009/06/09(火) 09:36:31ID:g6/5Uspu
codeigniter使ってる人いないの？
0226nobodyさん2009/06/09(火) 09:40:47ID:???
ZendFW導入して3ヶ月。だいぶコード書くのが楽になってきた。
構造がしっかりするのは良いもんだね。
0227nobodyさん2009/06/09(火) 09:46:08ID:???
>>225
おるよ
最初セッション関連に不満はあったけど、そこだけ自作に差し替えれば結構使える
0228nobodyさん2009/06/09(火) 10:10:03ID:???
セッション周りで自作って致命的だな。
0229nobodyさん2009/06/09(火) 10:15:14ID:???
え？
0230nobodyさん2009/06/09(火) 13:05:56ID:???
CodeIgniter(笑)
0231nobodyさん2009/06/09(火) 21:02:52ID:???
こでいｇにてぁ？(*‘ω‘ *)？
0232nobodyさん2009/06/09(火) 23:10:49ID:???
そこでkohanaですよ
0233nobodyさん2009/06/10(水) 01:30:26ID:???
んだ。
メジャー所一通り経由したが、kohanaは見通しよくてよい。
0234nobodyさん2009/06/10(水) 16:05:15ID:???
いらね
0235nobodyさん2009/06/10(水) 19:49:52ID:???
フレームワークに一番期待するものを述べよ

おれはDBラッパーが使いやすけりゃいいかな
0236nobodyさん2009/06/10(水) 22:28:38ID:???
フロントコントローラとディスパッチ先の管理
0237nobodyさん2009/06/11(木) 02:06:24ID:???
>>222がいってる、携帯対応は欲しいね。

後はHTMLデザイン関連フレームワークが同梱されてるようなものとか
あるといいなぁって思った。
Webサイトを作成するって段階において、一人で全部作成しようとすると
管理画面含め、画面作成部分が実は凄く面倒くさい。

まぁ、YUIとかそこらへんのCSSフレームワークとかを使えってことなのかもしんないけど。
0238nobodyさん2009/06/11(木) 02:31:40ID:???
携帯対応ってどんな？

絵文字<->絵文字変換
絵文字->画像変換
GET/POST文字コード自動変換
文字コード変換出力

ほかは？
0239nobodyさん2009/06/11(木) 09:30:25ID:???
IP・UserAgentでの判別
クッキー使えないときのセッション管理
0240nobodyさん2009/06/11(木) 12:42:28ID:???
組み込みのWEB管理画面が欲しいな、
phpMySQLAdminみたいな感じで、FWの情報を見たり、設定を変更出来たり、
各種設定が変更でたり、モジュールのユニットテスト支援してくれたい、etc

初期導入が楽なものより、
デバッグ機能が充実かつ容易な物が欲しい。
0241nobodyさん2009/06/11(木) 13:44:53ID:???
>>240
それってrhaco?

俺はまったく必要ないが。
0242nobodyさん2009/06/11(木) 17:39:18ID:???
>>240
そうそうそういうのいいね
0243nobodyさん2009/06/11(木) 19:34:23ID:???
>>241
rhacoなんてあるんだね。
さらっと見てみたけど、クラス名が他と被りそうな印象。

冗長だけどZendFrameworkみたいにパッケージ名を接頭子としてつけるとかして欲しいところだ。
0244nobodyさん2009/06/12(金) 13:17:24ID:???
普通はつけるよな
PEARパッケージにもできないし
0245nobodyさん2009/06/18(木) 17:22:53ID:???
>>237
PHPフレームワークで携帯といったらこれでしょ。

Ktai Library for CakePHP1.2
http://blog.ecworks.jp/ktai
0246nobodyさん2009/06/24(水) 00:42:05ID:???
http://slashdot.jp/security/article.pl?sid=09/06/23/0455215
Apacheに新たな脆弱性が発見されてPHPたちまち脂肪ｗｗｗ
0247nobodyさん2009/07/01(水) 17:27:59ID:???
>>246
結構好きです、脂肪シリーズｗｗｗ
いつも最新情報ありがとうございます＾＾
0248nobodyさん2009/07/14(火) 14:40:27ID:???
>>245
ネートは不幸な生育環境で非行に走っただけで元々の性質は悪くないだろ
変わったのではなく矯正施設の教育で本人の良さが引き出されただけ
ニートは成人するまで両親揃って何不自由なく育ったのに親掛かりを悪びれる素振りもない
人間そのものを変えるなんて事はどだい不可能なんだよ
彼らを何とかしようとするとき共存を考えるよりはそもそも始めからいない物としてカウントしない
そういった方向で何とかする方法を考えた方がいい
02492452009/07/14(火) 15:07:12ID:???
>>248
生きててごめんなさい ;-;
0250nobodyさん2009/08/13(木) 12:31:43ID:???
みんな 5.3 入れた?
0251nobodyさん2009/08/13(木) 13:51:32ID:???
5.2みたいにパフォーマンスが上がったわけじなくて
変な文法増えただけだろ？
ｲﾗﾈ
0252nobodyさん2009/08/13(木) 14:47:27ID:???
そんな餌に釣られるもんですかっ
0253nobodyさん2009/08/13(木) 15:55:34ID:???
バックスラッシュな時点で日本ではオワタな感じがする。
0254nobodyさん2009/08/13(木) 22:09:43ID:???
半角円記号とBackSlashを同じコードにしたやつはばくはつしてしまえばいい
ぎぎぎ
0255nobodyさん2009/08/14(金) 09:42:19ID:???
どこに割り当てればよかったと思う？
0256nobodyさん2009/08/14(金) 10:04:25ID:???
考えなしに記号を消費しまくったPHPが悪い。
0257nobodyさん2009/08/14(金) 10:45:14ID:???
PHPはそう遠くないうちに終わるだろう
0258nobodyさん2009/08/14(金) 11:04:06ID:???
記号消費といえば Perl な印象。

これだけ PHP アプリがあると、COBOL、Java のように負の遺産として残るんだろうなぁ。
0259nobodyさん2009/08/14(金) 15:15:42ID:???
PHPが何に取って代わるの？
0260nobodyさん2009/08/14(金) 17:32:44ID:???
>>259
何がPHPに取って代わるの？

じゃなくて？
今のところPHPに変わるものは無い気がするけど。

rubyやpythonはちょっと違う気がするし。
0261nobodyさん2009/08/14(金) 18:51:57ID:eBpbFkcS
>>251
そうなんだ。
GCの改良ってあったけど、パフォーマンスにはそんなに効かないのかな。

ディストリが採用するまで待つか。
0262nobodyさん2009/08/14(金) 21:12:33ID:???
PHP最強ということFAですね
0263nobodyさん2009/08/14(金) 22:43:59ID:???
強さは知らんが、PHPのポジションはそれなりに気づいてると思うけどな
0264nobodyさん2009/08/14(金) 23:38:42ID:???
言語記法としてはウンコ。
標準機能(extension含む)の手軽さではピカイチ。

言語としては ECMAScript が手軽かつ綺麗なのでいつか主流になると思う。
サーバサイド実装がほとんど無い現状だけども。
0265nobodyさん2009/08/14(金) 23:43:42ID:???
あんだけ普及してたPerlもいまじゃPHPと入れ替わったわけだし
いつかまた別のが来てもおかしくはないとは思うけど
当分はPHPが死ぬことはないと思うなー

まぁ入れ替わるとしても、風向きが変わってからとりかかりゃいいしな
なんだかんだで今後もあまり発展性のなさそうなものを新たに覚えるよりは
いま使いやすいのを使っておくのが無難かなと思うトコロ
0266nobodyさん2009/08/15(土) 00:16:27ID:???
PHPは当分残るだろうね。
良くも悪くも現状のWEB開発においては不満が少ないし、十二分に枯れている。

ブラウザとの親和性も含めるとECMAScriptがなんらかのきっかけで爆発的に普及する気がしないでもない。
0267nobodyさん2009/08/15(土) 00:51:22ID:???
ECMAScript はライブラリが充実したらいいと思う
0268nobodyさん2009/08/15(土) 01:43:47ID:???
Rhino on Railsかね、JSの本命は。
あれが来たらもしかしたら意外とサーバーサイドJS流行る可能性があるかもしれない。
webやるならいずれにせよ多少は触る言語だしね。
0269nobodyさん2009/08/15(土) 04:14:08ID:???
Rubyは導火線だったけど、爆発物じゃない、みたいな感
0270nobodyさん2009/08/15(土) 09:38:25ID:???
CodeIgniterは点火装置
0271nobodyさん2009/08/15(土) 09:48:54ID:???
PHPは爆発物では無い、もはや炭みたいなもの。
0272nobodyさん2009/08/15(土) 10:14:28ID:???
練炭ですね
0273nobodyさん2009/08/15(土) 10:57:07ID:???
炭はむしろほめ言葉だけどなｗ
0274nobodyさん2009/08/15(土) 11:46:04ID:???
褒めてるんだよｗ

ここまで手軽で高機能で普及していて枯れているWEB系言語は他に無い。
0275nobodyさん2009/08/15(土) 12:28:31ID:???
ガラッと変わってもいいから1度ちゃんと整理してほしいなあｗ
0276nobodyさん2009/08/15(土) 12:53:34ID:???
PHP7 か
0277nobodyさん2009/08/15(土) 15:58:23ID:???
便利にするには無駄に消費してしまった文字を使った
過去互換機能を切る必要があるからなぁ
ごっそり削ってほしいところがいっぱいあるんだけど、難しいんだろうなぁ
0278nobodyさん2009/08/15(土) 16:47:44ID:???
過去互換機能を残しても無くしても叩かれるんだからかわいそうね
0279nobodyさん2009/08/15(土) 17:51:38ID:???
引数の型指定に、stringとかが指定出来ないのが納得いかねぇんだよぉおおお･･･

設計した奴はまじでウンコ。
0280nobodyさん2009/08/15(土) 18:03:17ID:???
PHPではstringやらintにこだわることは意味をなさない
0281nobodyさん2009/08/15(土) 18:34:29ID:???
280みたいな人が多いから、PHP使いは見下されるんだよな･･･

厳密な型指定が出来るに越した事は無い。
0282nobodyさん2009/08/15(土) 18:49:26ID:???
お前は何を言ってるんだ
じゃPHPでない言語使えよ
0283nobodyさん2009/08/15(土) 19:03:12ID:???
>>281
型指定を理解できないと情けないかもしれないが。
型指定を理解して使わないなら問題無いじゃん。
0284nobodyさん2009/08/15(土) 19:36:51ID:???
コンパイル言語なら必要
0285nobodyさん2009/08/15(土) 20:16:37ID:???
何故関係無いことを持ち出すのか分かりません
0286nobodyさん2009/08/15(土) 20:30:08ID:YNZCA/eJ
>>279
その都度キャスト
>>284
Objective-C
0287nobodyさん2009/08/15(土) 21:13:23ID:???
型指定ができないせいで、かえって型を意識しないといけない、という局面は結構多いと思う。
case 0:とかな。
メリットは大きいが、全体を通してみるとデメリットの方が大きいと思う。

>284
問題はコンパイル言語かどうかじゃない。静的型言語か動的型言語かが問題。
0288nobodyさん2009/08/15(土) 21:28:15ID:???
PHPの場合は自動型変換がウンコだからデメリットの方がでかい
0289nobodyさん2009/08/15(土) 22:00:15ID:???
>>283
>>280が型指定を理解してるとは思えないがｗ

型指定の「強制」はPHP的にありえないには同意。

>>279は引数の型チェックとして型指定が出来るようになったのに、
なぜstringやintが指定できねーんだ･･･糞が！！って事を言いたかった。
だから中途半端で、頭悪そうな言語になっちゃうんだよ！
0290nobodyさん2009/08/15(土) 22:30:58ID:???
型指定が必要になるような規模のコードはPHPで書かないから問題ない
0291nobodyさん2009/08/15(土) 22:58:30ID:???
PHPってめちゃくちゃパーサーがしょぼいよな。print "$var全角"とかで平気でパースエラーが起きる。$varが展開されない。
0292nobodyさん2009/08/15(土) 23:11:23ID:???
>>291
いや、unicodeに対応するってことはそう言うことだよ。
"$varhankaku" と "$var全角" が同じように扱われるってこと。
"${var}全角" で幸せになれるかい?
0293nobodyさん2009/08/15(土) 23:31:34ID:???
if とか while とかでブロックのネストが深いところでシンタックスエラー起きると、エラー発生の行数が出ない事もある。
0294nobodyさん2009/08/15(土) 23:32:00ID:???
>>291
それをパースエラーと言わない。
たしかPHP4時代からのFAQだよね。
0295nobodyさん2009/08/15(土) 23:32:14ID:???
行数じゃなくて行番号だった
0296nobodyさん2009/08/15(土) 23:59:34ID:???
行番号が正確に出る言語ってあまり無いような･･･
そもそも if while を深くネストする状況が･･･
0297nobodyさん2009/08/16(日) 00:15:40ID:???
多分機能詰め込みすぎたピザメソドでも書いてんだろう
0298nobodyさん2009/08/16(日) 00:17:00ID:???
閉じ中括弧"}"忘れとかw

>>291=>>293 かな?
今時、print "$var全角" とか、深いネストとか。
大丈夫?
0299nobodyさん2009/08/16(日) 00:20:26ID:???
PHPだって普通は行番号出る。そんなの他の言語でも当たり前。ところが、コードが複雑になってくると、エラーメッセージから行番号が消えて、どこかにエラーがありますって。どういう理屈なのか知らない。
0300nobodyさん2009/08/16(日) 00:30:30ID:???
型指定の問題もこういう絶望的な。
http://d.hatena.ne.jp/JULY/20090622/p1
0301nobodyさん2009/08/16(日) 00:33:58ID:???
Javaとか日本語の変数名をつけられるしな。
0302nobodyさん2009/08/16(日) 02:15:06ID:???
>>299
組み方の問題。
デストラクタ内でエラー出すとそーなったりするね。
0303nobodyさん2009/08/16(日) 07:25:25ID:???
>>287
そうだ
0304nobodyさん2009/08/16(日) 12:22:34ID:???
最近は2重ネストですら潰したくなって困る。
3重くらいまでは潰すメリットのが大きいが、この辺まで来ると趣味だな。
0305nobodyさん2009/08/16(日) 14:07:49ID:???
型は、ぶっちゃけ指定したくなるときあるな。
32bit機で64bit整数使いたいときがあったりもする。
俺の脳が古いんだろうけどな・・・。
0306nobodyさん2009/08/16(日) 15:08:15ID:???
> 32bit機で64bit整数使いたいときがあったりもする。

32bit機で64bit整数使えない言語なんてあるの？
0307nobodyさん2009/08/16(日) 18:02:22ID:???
存在するかもしれないけど、現実にそんなもの使う機会はないな
0308nobodyさん2009/08/16(日) 18:41:28ID:???
>>306
phpだと、実数になっちゃうじゃん。
0309nobodyさん2009/08/16(日) 18:48:37ID:???
>>306
php -r '$a=pow(2,62);$a++;$b=$a&1;print "$a $b\n";'

32bit機だと 4.6116860184274E+18 0
64bit機だと 4611686018427387905 1

型指定したくなる気持ちも分かる。
0310nobodyさん2009/08/16(日) 23:12:58ID:???
gmpで任意精度整数を扱えるじゃない
0311nobodyさん2009/08/16(日) 23:24:45ID:???
扱う数字が32bitの範囲を超えそうだ！
というだけの理由で64bit環境を採用したうちの会社。
0312nobodyさん2009/08/17(月) 01:02:40ID:???
正しい判断じゃね？
0313nobodyさん2009/08/17(月) 07:42:31ID:???
>>310
それ、型指定じゃん。
だから、型指定したくなるって言ってるんだよ。
0314nobodyさん2009/08/17(月) 14:19:28ID:???
必要ならすればいいがな
PHPでどんなときも型指定が必須だし、したいってのもお門違いだと思うけど。
0315nobodyさん2009/08/17(月) 15:40:52ID:???
型指定したい時なんてそんなに頻繁にないし
したい時にチェックして例外投げりゃいいじゃん
0316nobodyさん2009/08/17(月) 16:08:29ID:???
>>314,315
型指定と型チェックは違うだろ。
まぁ、もういいわ。スレ汚しすまそ。
0317nobodyさん2009/08/17(月) 16:23:24ID:???
チェックで代用できるって言ってるんじゃん
頭固い子だな
0318nobodyさん2009/08/17(月) 16:43:31ID:???
基本やりたいことが実現するならやりたいようにやればいいけど。
人に強要しだすと面倒くさい。
メリットを強調してくれるならまだしも、趣味を押しつけられても困る。
0319nobodyさん2009/08/17(月) 16:46:24ID:???
誰が強要してるねん
0320nobodyさん2009/08/17(月) 18:37:19ID:???
>>317
型チェックで型指定は代用できないだろ。ちょっとは脳使え。
誰もおまえらにphpで型宣言しろとも言ってないよ。
おまえらには一生メリット無いだろうし。
0321nobodyさん2009/08/17(月) 18:41:42ID:???
>>320
へ？君の言ってる型指定ってどんなのを言ってるの？
0322nobodyさん2009/08/17(月) 20:38:50ID:???
リファレンスなりちゃんと用意してりゃ型指定とかしなくてもチェックだけで十分代用できると思うけどなぁ
0323nobodyさん2009/08/17(月) 23:06:54ID:???
<?php
$num = 'one';
switch($num){
　case 0:
　case 'zero':
　　echo 'zero';
　　break;
　case 1:
　case 'one':
　　echo '1';
　　break;
　case 2:
　case 'two':
　　echo '2';
　　break;
}
この「バグ」のおかげでenum代わりの定数に0が使えないし、定数値の中身を毎回毎回確認する羽目になる。unk。
0324nobodyさん2009/08/18(火) 01:10:39ID:???
数値文字列混在させたswitch-caseのcase 0:の不具合はたしかに変な動作だけど
そもそもcase文に数値と文字列を混ぜて使うあたり頭悪いと思う
0325nobodyさん2009/08/18(火) 01:57:57ID:???
<?php
define('C_ZERO',0); define('C_ONE',1); define('C_TWO',2);
function f($n) {
　echo $n . ' is: ';
　switch($n){
　　case (string)C_ZERO: echo '0'; break;
　　case 'zero': echo 'zero'; break;
　　case (string)C_ONE: echo '1'; break;
　　case 'one': echo 'one'; break;
　　default: echo 'default';
　}
　echo ' / '; var_dump($n);
}

f(0); f("0"); f("zero");
f(1); f("1"); f("one");
f(2); f("2"); f("two");
---
キャストができないなら "".CONST とかでもいい。多少気持ち悪いけど何より手っ取り早い
0326nobodyさん2009/08/18(火) 02:20:01ID:???
2を消し忘れてた
もう一年以上まともにPHP触ってないけど、多分これでいけるはず
0327nobodyさん2009/08/18(火) 11:45:35ID:???
文字列と数値を同じ演算子で比較する、しかも、0始まりの文字列を適当に変換する、無理があったな。
0328nobodyさん2009/08/18(火) 18:55:46ID:???
function hoge(string $str, int $int)
{
}

って書けるのと、function内で型チェックして例外投げるのが同じとか言ってる人は頭弱すぎだろ。
強制じゃなく、必要な箇所にだけ型指定出来ればPHPDocも出力出来るし、便利だと思うんだけどね。
0329nobodyさん2009/08/18(火) 20:22:43ID:???
いい加減にしろ
0330nobodyさん2009/08/18(火) 20:44:11ID:???
おのれでクラス作ってタイプヒンティング書けばいいだろ
0331nobodyさん2009/08/18(火) 21:19:02ID:???
つーかPHP使わなきゃいいんじゃね？
0332nobodyさん2009/08/18(火) 21:22:22ID:???
そもそもの発端が、>>279 の
型指定の中途半端さに対する指摘だったのに、
なぜ型指定自体の論争になるのか理解出来ない。

出来るに越した事は無いし、PHP以外を使えとかどんだけ盲目信者なんだと。
>>330とか本気でそう思ってるならプログラマ辞めた方がいい。
0333nobodyさん2009/08/18(火) 21:35:48ID:???
いやだってPHPは文字列も整数も同じように扱えたほうが便利だよねってとこから
言語思想がスタートしてるんだから自分がPHPを選んだ上でそれを言うのは非常にナンセンスかと
0334nobodyさん2009/08/18(火) 21:44:21ID:???
入力も出力も文字列だしな
いちいち内部で変換するとかC/C++で嫌なほど苦労した
0335nobodyさん2009/08/18(火) 21:48:46ID:???
自分でextention書けばいいだけ
PHPの型指定に文句言うのは小学生までだよねｷｬﾊﾊｷﾓｰｲ
0336nobodyさん2009/08/18(火) 21:59:41ID:???
checkdate()は$_POSTデータ直で渡したら転けた。
微妙にintオンリーとかあるよね。
0337nobodyさん2009/08/18(火) 22:44:33ID:???
>>333
PHP5でOOPよりに思想が変化したじゃん。
引数として型指定出来るようになって、
それはPHPの良さを保ちつつ、必要な箇所は堅牢に出来るってイメージだったんだけど、
stringとかintを型指定出来ない理由が不明なんだよね。


気持ち悪いとは思わないのかなと。
0338nobodyさん2009/08/18(火) 22:48:16ID:???
>>333
＞PHPは文字列も整数も同じように扱えたほうが便利だよねってとこから
＞言語思想がスタートしてる

初耳だ
ソースは？
0339nobodyさん2009/08/18(火) 23:15:59ID:???
クラスタイプヒンティングだけで十分だけど
0340nobodyさん2009/08/18(火) 23:21:21ID:???
>>339

初耳だ
ソースは？
0341nobodyさん2009/08/18(火) 23:41:38ID:???
ダックタイピングはむしろ美徳だろ
原始人乙としか言いようがない
0342nobodyさん2009/08/18(火) 23:44:31ID:???
誰もダックタイピングの話なぞしていない
0343nobodyさん2009/08/18(火) 23:48:57ID:???
stringやintを型指定できるようにするくらい
コスト的には何でもないように思えるが、しない理由は何なのだろうか？
ユダヤ教徒の宗教上の理由か？
0344nobodyさん2009/08/18(火) 23:55:18ID:???
存在しないクラスStringでタイプヒンティングして
出たエラーをハンドリングして判定したらいいんじゃね？
0345nobodyさん2009/08/18(火) 23:56:17ID:???
is_string / is_int とかあるんだから内部的には型情報持ってる気がするんだけどね。

ネームスペースのバックスラッシュもそうだけど、
何らかの矛盾が生じる実装になっちゃってて技術的に難しいのかもね。
0346nobodyさん2009/08/19(水) 00:03:44ID:???
>>344
そんな面倒な事するなら普通に型チェックするコード書く方が早くね･･･？

あとStringクラスが実在したらどーすんのｗ
0347nobodyさん2009/08/19(水) 00:05:41ID:???
どんな型であれ受け取れるのが前提にあるとかそんな感じなんじゃないの
一般的な意味でのオーバーロードもできないんだし

まぁ型チェック程度なら一度値書きゃ使いまわせるし
必ず値がこれだってわかってるなら決め打ってチェックかけなくてもいいしな
例外？しるか、みたいないい加減な実装で、使える値はリファレンス見るか察してくれ
ってのがPHPなんだと思ってる
0348nobodyさん2009/08/19(水) 02:11:50ID:???
そりゃPHPが初心者向けに作られた言語だからだよ。Perlがuse strictを実質的に強制するようになって、一気にユーザが減った。
0349nobodyさん2009/08/19(水) 13:16:10ID:???
>>337
実装することは可能ではあるがPHPでそれをやっても価値がないということ
POSTから文字列で渡ってくる通し番号のためにString→Int変換してから関数に渡すなんてのはもう古い
0350nobodyさん2009/08/19(水) 15:55:22ID:???
気持ち悪い

根拠が薄い時に使われる事が多い
0351nobodyさん2009/08/19(水) 18:18:58ID:???
>>349
論点ずれすぎ。
クラスタイプヒンティング自体が実装されている以上、意味が無いという事は無い。

あと例えが頭悪すぎかつ意味不明。
そんな用途しか思いつかない君には意味が無いのかもしれないな･･･
0352nobodyさん2009/08/19(水) 19:10:50ID:???
>>351
こんな所で他人に「頭悪い」とか言ってる暇があったら
頭良いお前が気に入るようにPHPの言語仕様に実装しちゃえば
いいと思うけど〜
0353nobodyさん2009/08/19(水) 19:12:04ID:???
すごい言い様だな
0354nobodyさん2009/08/19(水) 19:24:39ID:???
>>349
え？ＰＯＳＴから数値を受け取りたい場合、普通は型チェックしてｉｎｔに変換するよね？
0355nobodyさん2009/08/19(水) 19:47:41ID:???
HTTPは数値も全て文字列で渡されるからなぁ。

これがC言語であっても、結局は文字列から数値に変換する必要があるわけだ。
手間は何も変わらない。
0356nobodyさん2009/08/19(水) 19:50:18ID:???
>>349
それ違う話。難しい話してごめんな。

>>352
オマエモナー
0357nobodyさん2009/08/19(水) 19:51:38ID:???
あーだこーだ言う前にここ二ヶ月くらいのinternal読んどけ。
0358nobodyさん2009/08/19(水) 20:21:23ID:???
型指定否定派はプログラマとしての能力(デバッグ力)が低そうなイメージだな･･･

・privateとかいらないよね！
・interfaceとか何につかうの？ｗ
・abstract？面倒なだけじゃんｗ
・そもそもclass化すると速度遅くなるし！
・テンプレートエンジン？いらねｗ　PHP自体がテンプレートエンジンだからｗ
0359nobodyさん2009/08/19(水) 20:24:49ID:???
残念だがそれらは型指定とは関係ない
0360nobodyさん2009/08/19(水) 20:26:51ID:???
あくまでイメージだよ･･･使いこなせないから不要って人がPHP使いには多い気がする
で、他の言語もかじってる人がツッコミを入れると袋だたきにされる･･･と。
0361nobodyさん2009/08/19(水) 20:38:22ID:???
最初に触った言語がPHPの人ってかわいそうだよね。
その後もプログラマーとして成長できなさそう。
0362nobodyさん2009/08/19(水) 20:53:47ID:???
自分がついていけないから、言語の進化を否定している感じだよね
無名関数とかネームスペースとか、浸透しなさそうだなぁ
0363nobodyさん2009/08/19(水) 21:13:37ID:sk0qCFj1
むしろ型指定にうるさいだけの奴の方が初心者くせー
分かりきってること言ってるだけだし
代替案示されてもふてくされる
ただの馬鹿ですね分かります
0364nobodyさん2009/08/19(水) 21:36:16ID:???
コード内で型チェックして例外投げるのが面倒だから、
組み込み型もタイプヒンティングしたいって話じゃないの？

代替え案なんてあったっけ･･･？
0365nobodyさん2009/08/19(水) 21:43:58ID:???
// 型指定あり
function hoge(string $str, int $int, boolean $bool)
{
}

// 型指定無し
function hoge($str, $int, $bool)
{
if (!is_string($str)) new throw InvalidArgumentException();
if (!is_int($int)) new throw InvalidArgumentException();
if (!is_bool($bool)) new throw InvalidArgumentException();
}
0366nobodyさん2009/08/19(水) 21:54:42ID:???
オプションとしてあっても誰も困らないんだから
あった方がいいのは疑問の余地がねーんだよ
ただ文句言ってるだけなのが頭悪い
0367nobodyさん2009/08/19(水) 22:00:29ID:???
PHPのマニュアルでは、型指定も戻り値指定もあるんだよねぇ･･･

PHPDocで同様のマニュアルを出力したいんだけど、
現状では@paramに型までキッチリ書かないといけないから面倒すぎる。
0368nobodyさん2009/08/19(水) 22:06:59ID:???
型指定ﾏﾝｾｰ派は、コーディングのときなんかに、決められた型しか渡せないのがわかるから、
バグを作りこむ可能性が少ない、とか、自分が書くメソッドでチェックしなくてすむから便利つってて、
チェック処理でいいだろ派は、渡される値の型がわからないものを処理する場合
メソッド内でチェックするか外でチェックするかの違いしかないから、
結局チェックかませりゃいいだけじゃん
つってる
そこらへんをお互いが理解してないのか知らんけど、話かみ合ってねーだろｗ

つか、指定できれば便利、ってのはみんなわかってるだろう
でもぐだぐだ不満垂れようが、結局いまのPHPじゃできないんだから
ここで愚痴るのも馬鹿な話というかお門違い。フレームワークにも関係ねーし

だいたいそういうのはPHPを使うと決めた時点で割り切るべき機能だと思うけどな
型指定できない仕様が向いてないもの作るなら、まずPHPを選択肢から除外するべきじゃ
0369nobodyさん2009/08/19(水) 22:11:17ID:???
>>368
最後の2行が余計だな。
スレ違かもしれんが、PHP5以降に対する要望としてはお門違いでも無いし、
嫌なら他の言語使えってのは極論過ぎる。
0370nobodyさん2009/08/19(水) 22:23:43ID:???
お門違いだよ
0371nobodyさん2009/08/19(水) 22:27:23ID:???
お門違いじゃないよ
0372nobodyさん2009/08/19(水) 22:27:48ID:???
理由を言えよ、たこ助野郎
0373nobodyさん2009/08/19(水) 22:30:50ID:???
みんなで芋堀りすればいいんじゃね？
0374nobodyさん2009/08/19(水) 22:34:53ID:???
タイプヒンティング
http://php.benscom.com/manual/ja/language.oop5.typehinting.php
0375nobodyさん2009/08/19(水) 22:36:05ID:???
落ちて久しいPHP総合スレたててそっちでやれｗ
0376nobodyさん2009/08/19(水) 22:40:49ID:???
>>369
お前がいやだと思ってることはもう十二分にわかったから、日記帳にでも書いてろｗ
0377nobodyさん2009/08/20(木) 09:41:50ID:???
ちょっと質問なのだけど、
2〜3枚の軽いけど、DBを一応使う。みたいな要件の時FW使うまでもないかなと考えてるのですが、
そういう時皆はどうやって作ってますか？
規模に関係なくFW使ってる？
それとも、pdoとか使ってべた書き？
0378nobodyさん2009/08/20(木) 12:55:48ID:???
>>377
俺個人でやるならベタで書くな。その方が軽いし管理も楽だ。
仕事でやるなら周りのシステムに合わせておく。
0379nobodyさん2009/08/20(木) 16:29:50ID:???
>>355
ああ、それは大きいな。しょせんHTTP（というかHTML）には限界がある。
try {
int $num = $_REQUEST['age'];
} catch (Exception $e) {
die("age is not number");
}
こういうのがベスト。連想配列とかオブジェクトを直接REQUEST出来たり名。
0380nobodyさん2009/08/20(木) 17:23:29ID:???
>>379
なにそのコードこわい。

HTTPの限界？そもそも型を保証するようなプロトコルじゃないだろう。
0381nobodyさん2009/08/20(木) 18:26:24ID:???
phpとかhttpとか限界じゃなくて仕様と割り切るのが精神衛生上いいし、そういうもんじゃないのか
0382nobodyさん2009/08/20(木) 20:18:13ID:???
>>378
レスどうもありがとうございます。

コピーしてちょっと設置とか取り回しが面倒だし、
propelだけ入れるってのも手間かけるメリット薄いので、躊躇してました。
0383nobodyさん2009/08/20(木) 20:28:03ID:???
コツコツと自前の関数郡作ってる
そして会社には絶対に持っていかない
0384nobodyさん2009/08/20(木) 20:55:07ID:???
>>379
小さいプロジェクトはいいな。
0385nobodyさん2009/08/20(木) 21:10:24ID:???
>>379 のコードが理解出来ないのは俺だけか
0386nobodyさん2009/08/20(木) 21:39:30ID:???
Integer型の $num に Integer 以外の型で値が渡ってきたら
おかしいことなので例外が発生。
そのとき「値がおかしいぜ！」ってダイイングメッセージ残して
phpが死ぬって意味だろ。

しかしせめて
int $num = Integer.parseInt($_REQUEST['age']);
とかだろ。
0387nobodyさん2009/08/20(木) 22:03:58ID:???
例外の使い方が不適切なような・・
0388nobodyさん2009/08/20(木) 22:11:25ID:???
想定外の値が来たからキャストエラーだろ？
何か問題でも？
0389nobodyさん2009/08/20(木) 23:16:59ID:???
PHPの無茶キャストっぷりを考えたら意図した通りに動くとは思えないがｗ


そもそも、それはPHPのコードなのか？
0390nobodyさん2009/08/20(木) 23:42:04ID:???
論争

静的および強い型付けの支持者と動的および自由な型付けの支持者の間では衝突が度々おきる。
前者のグループは厳密な型付けの使用によって、処理系がより多くのエラーを
問題が大きくなる前に発見できるようになると主張している。
後者のグループはより気軽な型付けによってコードはよりシンプルなものになり、
そのようなコードは解析しやすいとされるので、エラーは減少すると主張している。
型推論がある言語では型を手で宣言する必要はほとんどないので、強い型付けに伴う開発のオーバーヘッドは低減される。

個人がどのグループに分かれるかは、開発しているソフトウェアの種類やチームのメンバーの能力、
他のシステムとの対話性の度合い、開発チームの規模などに依ることが多い。
少人数で小回りのきくプロジェクトには気軽な型付けがより合い、フォーマルで大人数で仕事が分断されている
（プログラマ、アナリスト、テスト部隊、など）プロジェクトは厳密な型付けのほうがうまくいくことが多い、と結論づける者もいる。
0391nobodyさん2009/08/20(木) 23:51:57ID:???
一般に動的な型付けを持つ言語では型の特性に合わせた最適化(例えば常に浮動小数点レジスタを用いるなど)ができないので、
実行速度という面では静的型に劣ると考えられている。反面多態性や記述の容易さで動的型は融通が利き、
Smalltalkなどのオブジェクト指向言語、スクリプト言語は動的型を採用するケースが多い。

動的型と静的型のどちらが安全なプログラムを記述できるのかは長年論争の的であるが、
双方とも適した問題領域、適した開発スタイルが存在し、異なった安全観念を持つ点を理解しなければならない

通常、静的型付けはオペレーティングシステムやシステムプログラムのような大規模で厳密性が要求される領域に適合するといわれている。
反面最初の型定義を誤ると一部分の影響が全体に波及すること、また柔軟性に乏しくわずかな変換に手間のかかる経路を用意したり
同じような機能を型別に実装しなければならないことなど、いわばお役所仕事的な煩雑さを伴うという弱点を持つ。
（なお近年の研究により静的型付けの言語も文脈から型を推論する型推論能力を持つなど簡略化の方向へ向かってはいる）

一方動的型付けの言語ではそもそも対象に特定の構造を期待しないため変更への対応は柔軟である。
特に配列、辞書、集合といったコレクションの利便性が顕著で、そのため近年いわゆるスクリプト言語は多くが動的型付けを採用している。
動的型付けの難点である最適化の弱さは、コンピューターの能力が増すことで相対的に小さな問題になっており、
スクリプト言語を中心に今後も動的型付けは発展するものと思われる。

0392nobodyさん2009/08/20(木) 23:55:54ID:???
実行パフォーマンスには期待していない。
部分的に強い型付けが出来る程度がPHPの理想系な気がする。
0393nobodyさん2009/08/20(木) 23:58:39ID:???
おまえらにscalaを紹介するよ
0394nobodyさん2009/08/21(金) 00:09:49ID:???
どんなに言語が簡単で優れていても、
ライブラリが揃ってない時点でPHPerは移行しないだろ。

なぜなら自前で実装する知識が無いから。
フォームデータのパースすら出来ない人がほとんどなんじゃない？
0395nobodyさん2009/08/21(金) 00:12:22ID:???
つーまーりー？
0396nobodyさん2009/08/21(金) 00:25:19ID:???
仕事で使う言語を自由に選べたらこんなスレにいねーよ
0397nobodyさん2009/08/21(金) 00:28:39ID:???
まったくだな
0398nobodyさん2009/08/21(金) 00:30:56ID:???
だーけーどー？
0399nobodyさん2009/08/21(金) 01:28:55ID:???
>>377
俺は自作のフレームワークもどきを使っているよ。
最小でPHPファイル1つで完結する。
フレームワークというより、ファイルの置き方を決めた程度だけどな。

PHPを使わないでベタで書いたものから
簡単に移行できる設計になっているから、
ベタでかいていたけど、PHPファイルが数枚になって
ディレクトリ構造とか考え出したときに、すぐに変更できる。
0400nobodyさん2009/08/21(金) 01:45:00ID:???
それを今すぐ公開しろ。今すぐだ
0401nobodyさん2009/08/21(金) 02:00:22ID:???
>>399
CakePHPスレで見た希ガスwww
http://pc11.2ch.net/test/read.cgi/php/1236563737/617
0402nobodyさん2009/08/21(金) 02:28:35ID:???
さすがだな。スネーク
0403nobodyさん2009/08/21(金) 03:10:01ID:???
それフレームワークとは言わなくね
0404nobodyさん2009/08/21(金) 05:33:23ID:???
>>377
もう、ちいたん+pdoでええやん
0405nobodyさん2009/08/21(金) 12:24:36ID:???
Agavi による MVC プログラミング入門
http://www.ibm.com/developerworks/jp/xml/library/x-agavipt1/?ca=drs-jp

何故か今agaviが！
0406nobodyさん2009/08/21(金) 16:00:04ID:???
var_dump(strpos(100, 10));
var_dump(strpos(100, '10'));

何で結果が違ってくるの？
0407nobodyさん2009/08/21(金) 16:29:35ID:???
>>406
マニュアル見ろよw
0408nobodyさん2009/08/21(金) 17:15:19ID:???
>>407
型のことなんてどこに書いてあるの？
0409nobodyさん2009/08/21(金) 17:34:09ID:???
>>408
ttp://jp.php.net/manual/ja/function.strpos.php

> needle が文字列でない場合は、 それを整数に変換し、
> その番号に対応する文字として扱います。
0410nobodyさん2009/08/23(日) 14:47:30ID:???
php 5.3 で、HTML中の <?=$val> のような変数表示に関して、仕様変更ありました?
0411nobodyさん2009/08/23(日) 15:53:07ID:???
うん
0412nobodyさん2009/08/23(日) 15:53:16ID:???
php 5.3じゃなくても <?=$val> は構文エラーになると思うけど。
0413nobodyさん2009/08/24(月) 02:01:45ID:???
short_open_tag=Onにすれば、構文エラーじゃないと思ったが、
よく見たら<?=$val ?>じゃないのね。
そりゃ構文エラーだわ。
0414nobodyさん2009/08/24(月) 09:11:24ID:???
>>413
ありがとう。short_open_tag スイッチですね。
0415nobodyさん2009/08/24(月) 12:42:48ID:???
short_open_tag使わない奴はただの暇人
キー打つ時間がもったいねーだろ
0416nobodyさん2009/08/24(月) 14:52:54ID:???
そうかそうか
0417nobodyさん2009/08/24(月) 15:10:12ID:???
>>416
いや、ユダヤだと思うよ
0418nobodyさん2009/08/25(火) 00:20:28ID:???
ははっ ワロス
0419nobodyさん2009/08/25(火) 13:33:43ID:amBbmp7F
>>415
補完を知らない暇人乙
0420nobodyさん2009/08/25(火) 16:12:34ID:???
>>399

俺も自作って言うか、ZendFWを自分の使い易いようにラッパーした物使ってる。
つうかZendFWが予想以上に出来る子だった。
0421nobodyさん2009/08/25(火) 17:23:39ID:???
>>419

<?=$val?>
<?php echo $val ?>
補完でどうにかなるもんなの？
0422nobodyさん2009/08/25(火) 17:36:36ID:???
>>420
やぁ俺。だが現実的にphp4の環境で動いているところが多くて、結局自前ラッパーフレームワーク互換の
php4用自前フレームワークもどきを作って2つをメンテナンスしていく羽目になって泣いている。えーん。
0423nobodyさん2009/08/25(火) 18:57:14ID:???
PHPとはちょっと関係ないんだけど、HTTP Status コードについて相談したいことがあります。
フォーム入力のバリデーションをしてエラーがあった場合、HTTP Response のステータスコードは何にすればいいでしょうか。
今までは特に指定してなかったので、結果として 200 OK を使っていたわけですが、
今度から Ajax 用のAPIを用意することになり、フォーム入力にエラーがあるかどうかを
HTTP Response のステータスコードで表すことになりました。
しかしどのステータスコードを使っていいのかよくわかりません。

フォーム入力にエラーがあることを表すにはどのステータスコードが適切でしょうか。
このスレはレベルの高い人が多いようなので、アドバイスをよろしくお願いします。
0424nobodyさん2009/08/25(火) 19:42:58ID:???
全く持ってすれ違い
そもそも用途が違う

ページリクエストに対して返すもので、コンテンツのエラーは管轄外
0425nobodyさん2009/08/25(火) 20:10:47ID:???
>>423
通信自体は成功しているから200にしておくべき
XMLかJSONかわからないけど、status項目等を追加してシステム独自のエラーコードなりエラーメッセージで判断するのが普通と思われる。
0426nobodyさん2009/08/25(火) 20:33:19ID:???
>>421

補完云々以前に
＞ <?=$val?>
＞ <?php echo $val ?>

こういうコーディングする時点で終わってる。
0427nobodyさん2009/08/25(火) 21:18:26ID:???
>>426

コーディング云々以前に
PHP使ってる時点で終わってる。
0428nobodyさん2009/08/25(火) 21:28:37ID:???
2ch使ってる時点で終わってる
0429nobodyさん2009/08/25(火) 21:54:16ID:???
>>425
通信自体は成功しているから200にしておくべき

これは無いだろう
0430nobodyさん2009/08/25(火) 21:59:54ID:???
うむ
0431nobodyさん2009/08/25(火) 22:19:15ID:???
<?php を間違えて<? って書いてた。
PHP5.3に入れ替えてプログラム実行したら
ソースコードが表示されて混乱した。
0432nobodyさん2009/08/25(火) 22:20:42ID:???
>>423
400 Bad Requestじゃね？
0433nobodyさん2009/08/25(火) 22:30:20ID:???
>>431
まじ？恐ろしすぎる
コード丸見え事件が頻発しそう
0434nobodyさん2009/08/25(火) 22:55:34ID:???
>>433
うん。詳しくは検証していない。

php.iniで設定できるのかもしれないし、
自分がやったのがCLIだったので、CLIだけかもしれないし、
include/requireで読んでいるものは関係ないかもしれない。
が詳しくは検証していない。

考えてみれば、パスワードが含まれたファイルでミスってたら危険だね。
0435nobodyさん2009/08/26(水) 00:35:59ID:???
素人すぎるわ
くだすれ行け
0436nobodyさん2009/08/26(水) 02:01:58ID:???
>>433-434
頭悪いとかってレベルじゃねーぞ…
そういう基本的なことすら理解してないって、よく恥ずかしげもなく宣言できるもんだなｗ

だいたいショートタグなんて使う意味がないだろ
1ファイル中に何度も書くもんでもないし、XMLとぶつかるし、こういうアホ達がやらかすし、
使わないようにしよう言われるようになってからもだいぶ久しいってのに…
0437nobodyさん2009/08/26(水) 02:29:31ID:???
中学生乙ｗ
0438nobodyさん2009/08/26(水) 02:31:38ID:???
>>423
そもそもHTTPリクエストに対するレスポンスのステータスを示すものであって
一般的にはバリデート結果の通知に用いるような使い方はするべきでない
そういうアホなことやってる企業とかもあるにはあるし、
解釈の仕方ではそういう用途に使えると曲解できなくはないと思うけど、
悪いこと言わんからレスポンスのなかにフラグでも持たせて判断するべき

つーかスレ違いだし、まず ftp://ftp.rfc-editor.org/in-notes/rfc2068.txt 嫁
0439nobodyさん2009/08/26(水) 02:33:38ID:???
431、433はさすがにネタだと思いたいｗ
0440nobodyさん2009/08/26(水) 03:57:01ID:???
php使ってるやつは頭悪杉ｗよくこんなダサいの使えるな
センスを疑うよ、まったくｗｗｗ
0441nobodyさん2009/08/26(水) 10:01:33ID:???
わざわざ言いに来たお前はもっと馬鹿だということに気づいた方がいいよ
0442nobodyさん2009/08/26(水) 10:57:59ID:???
最近は文章も読めないガキが多いな。

単に、<? と ”間違って” 書いただけだろ。

俺は人生で今まで一度も間違ったことが無いってやつは
挙手しろよ。

うそつき認定してやっから（爆笑）
0443nobodyさん2009/08/26(水) 12:45:13ID:???
キリンさんが好きです。でもショートタグはもっと好きです。
0444nobodyさん2009/08/26(水) 13:16:19ID:???
ショートタグ使う勇気もない奴は一生童貞だろうなｗ
0445nobodyさん2009/08/26(水) 13:29:22ID:???
ショートタグ使う奴は、フレームワーク以前の問題だろｗ
コードレビューしたら笑われても文句言えないレベル。

>>421
スニペットとかコードテンプレートでぐぐれ。
0446nobodyさん2009/08/26(水) 14:56:15ID:???
ショートタグって悪い理由ないんだってね。
0447nobodyさん2009/08/26(水) 14:56:32ID:???
良い理由がないよ
0448nobodyさん2009/08/26(水) 14:59:35ID:???
良い理由はあるよ。キータイプの数が少ない。
0449nobodyさん2009/08/26(水) 15:03:19ID:???
ショートタグ否定する奴に限ってHTMLエスケープもろくにしてないんだから
参っちゃう
0450nobodyさん2009/08/26(水) 15:09:20ID:???
XML と誤読するとか
0451nobodyさん2009/08/26(水) 15:14:27ID:???
PHPが書かれたファイルにXMLが書かれてるケースなんてほとんどないだろ
てかHTML5が出たからXMLなんてもはや下痢便以下の存在だろ
そんなもののために便利なショートタグ使わないことが許されるのは小学生まで
0452nobodyさん2009/08/26(水) 15:18:50ID:???
正直どうでもいい。
0453nobodyさん2009/08/26(水) 15:29:16ID:???
>PHPが書かれたファイルにXMLが書かれてるケースなんてほとんどないだろ
えっ
0454nobodyさん2009/08/26(水) 16:18:36ID:???
ブラウザの対応状況とかから言って、実際にはXML宣言なんてほとんど使わないものな。ドコモ向けにXHTMLで書くときぐらいか。
どうしてもって言うなら、JSPみたいに<%なんかに変えちゃった方が良かったと思う。数少ないPHPのメリットなのに。
0455nobodyさん2009/08/26(水) 16:28:09ID:???
PHP で RSS や SOAP の動的生成とかしない子がいる
04564232009/08/26(水) 16:41:30ID:???
>>425
>通信自体は成功しているから200にしておくべき
えー、そうでしょうか。「通信の成功」って、どのことを指してます？

>XMLかJSONかわからないけど、status項目等を追加してシステム独自のエラーコードなりエラーメッセージで判断するのが普通と思われる。

そういう項目を追加したくないので status code を使いたいんですけどだめですか。

>>429
>通信自体は成功しているから200にしておくべき
>
>これは無いだろう

ですよねー。

>>432
>400 Bad Requestじゃね？
最初はそのつもりだったんですけど、仕様書によると、400はHTTP Requestの構文が違っていることを表すものなので、
validation errorを表すのには不適切ではないかとおもいました。（それで今回質問したわけです。）
0457nobodyさん2009/08/26(水) 16:49:29ID:???
ショートタグがPHPのメリットとか言ってる人は、互換性やPEAR規約を知らないんだろうか。
少なくとも推奨されるべきものでは無い。
04584232009/08/26(水) 17:01:58ID:???
ttp://www.studyinghttp.net/status_code#Client_Error
こちらのページを参考にした結果、422 Unprocessable Entity を使うことにしました。
このステータスコードは、たとえば送信されたXMLデータが妥当でなかった場合などに
使われるようなので、validation error のときもこれでいいだろうと思います。
以下引用：

> 422 Unprocessable Entity
>
> | 422 (Unprocessable Entity) ステータスコードは、サーバはリクエストエンティ
> | ティの内容タイプは理解でき (そのため 415 (Unsupported Media Type) ステー
> | タスコードは不適切である)、リクエストエンティティの構文は正しい (従って
> | 400(Bad Request) ステータスコードは不適切である) が、含まれる命令を処理
> | できないという事を意味する。 例えば、XML リクエストボディが
> | well-formed である (すなわち、構文的に正しい) が、意味的に誤った XML 命
> | 令を含む場合、このエラー状態が生じるであろう。
>
>
> ステータスコード 422 は、WebDAV について記述されている RFC 4918 内で定
> 義されています。
>
> リクエストに同封されるエンティティが処理できない場合に、このステータス
> コードが返されます。 例えば、上の文にあるように、エンティティ中の XML
> が妥当{valid} でない場合が考えられます。


すれちがいすみませんでした。
0459nobodyさん2009/08/26(水) 17:49:16ID:???
>>451

＞ PHPが書かれたファイルにXMLが書かれてるケースなんてほとんどないだろ

確かに

＞ てかHTML5が出たからXMLなんてもはや下痢便以下の存在だろ

HTML5の規格は調べてないから知らないが、どうせXML文書だろ。
XMLとXHTMLの違いも分からないのか？


＞ そんなもののために便利なショートタグ使わないことが許されるのは小学生まで

非推薦のショートタグを使うことが許されるのは素人だけ
0460nobodyさん2009/08/26(水) 18:05:09ID:???
XML宣言は必須じゃないしね。

ショートタグの何を恐れているのか
理解できない。
0461nobodyさん2009/08/26(水) 18:40:42ID:???
>>456,458
それも違うと思うが
0462nobodyさん2009/08/26(水) 19:10:34ID:???
PHPってバージョン4になってから以降、開発者のセンス悪すぎ。ショートタグを止めたと思ったら、gotoを導入するとか。
0463nobodyさん2009/08/26(水) 19:27:27ID:???
>>460
未対応設定になってるサーバがあったり、
顧客の社内規約で禁止になってたりするからじゃない？
個人的にはオープンソースなスクリプトでショートタグ使ってたら、一気に醒める。
利便性より汎用性。
0464nobodyさん2009/08/26(水) 19:39:48ID:???
>>462
それ以前からどうしようもないセンスだったと思うが。
0465nobodyさん2009/08/26(水) 19:48:29ID:???
>>462
finally 実装しないでgotoだもんな。
しかも try/catchより goto の方がコードが綺麗になるとか言っちゃうくらいだし･･･
PHPユーザの質の低さがばればれだよね。
(ネームスペースもgotoもユーザ意見で最終決定したと思われる)


ここもいずれ、goto厨が湧いて「便利なのになんで使わないんだ！」とか言い出すんだろうね。
0466nobodyさん2009/08/26(水) 20:36:58ID:???
<?php

goto hell

hell: die('＼(^o^)／ｵﾜﾀ');
0467nobodyさん2009/08/26(水) 20:41:55ID:???
>>466

<?php echo "クソワロタwww"; ?>
0468nobodyさん2009/08/26(水) 23:06:50ID:???
すごく…自演くさいです…
0469nobodyさん2009/08/26(水) 23:09:07ID:???
?>を書く必要があるような書き方をしたくないのでショートタグなんて絶対使いません
0470nobodyさん2009/08/27(木) 00:16:44ID:???
ショートタグ使わん人はView Templateはどう書いてるの？それともSmarty？
0471nobodyさん2009/08/27(木) 00:30:50ID:???
Smarty
0472nobodyさん2009/08/27(木) 00:59:08ID:???
ショートタグ否定派はスマーティー派かｗ
通りで・・
0473nobodyさん2009/08/27(木) 01:01:36ID:???
スマーティー（(笑)）
0474nobodyさん2009/08/27(木) 01:09:14ID:???
主にコード書く側の人間で率先してショートタグ使おうなんて人はいないだろう
VIEW専門の無知な奴がよく理解もしてないのにショートタグ使って俺玄人だぜ気分に浸って
>>431,433みたいな事とやらかしてしまうんじゃろうて
0475nobodyさん2009/08/27(木) 02:19:34ID:???
ショートタグに違和感憶えない奴はどう考えてもプログラマには向いていない。
0476nobodyさん2009/08/27(木) 02:58:15ID:???
>>421
<?=[ENTER] で <?php echo | ?> とか
<?=h[ENTER] で <?php echo htmlspecialchars(|) ?> (パイプがキャレット位置)とか
したらいいじゃん。
0477nobodyさん2009/08/27(木) 08:19:45ID:???
View TemplateにPHP使ったことない。コメントとかどうやって書くの?

Yahoo!とかGooのサービスのHTMLソース見るとHTMLのコメントだらけ。
0478nobodyさん2009/08/27(木) 08:29:29ID:???
えっ
0479nobodyさん2009/08/27(木) 10:32:53ID:???
なんとｗ
0480nobodyさん2009/08/27(木) 11:01:40ID:???
<?php echo コメント > /dev/null ?>
かな?
0481nobodyさん2009/08/27(木) 14:21:24ID:???
ここ本当にフレームワークのスレかよｗｗ
Smarty厨は隔離スレに帰れｗｗｗ
0482nobodyさん2009/08/27(木) 15:16:20ID:???
ミスリードする人間に反応しすぎじゃないかな。
こうやってスレ違いに厳しくなってしまうんだけど、しょうがない部分もあるよね。
0483nobodyさん2009/08/27(木) 23:11:52ID:???
ショートタグ自体は別に悪では無いが、
非対応環境があるから、フレームワークを作る上では敬遠されている。

バージョンアップや設定ミスで、ショートタグが動かなくなった場合のリスクを考えると、あまり賢い選択では無い気がする。
0484nobodyさん2009/08/27(木) 23:31:50ID:???
どっちでもいいなそんな事
0485nobodyさん2009/08/27(木) 23:46:10ID:???
ソースコード公開するなら関係するよな
でもここはフレームワークについて語るスレ13
　　　　　　 　 　 ＿_
　 　 　 　 , ‐' ´　　　｀`‐、 　 　 　 　 　 　 ／￣:三}
.　　 　 ／,. -─‐- ､.　　 ヽ　　　　　　　　/　　 ,.＝j
　＿,.:_'＿＿＿＿＿_ヽ、　.!　　　　 　 .／ 　 _,ﾉ
　 `‐、{　へ　　'ﾞ⌒　`!~ヽ. !　　　　 ／{.　　/
　　　 ｀!　しﾟ　 （　ﾟj　`v‐冫　　　, '::::::::ヽ､/ 　　　　そんなことよりフレームワークの話しようぜ！
.　　　 {.l 　 '⌒　 　 　 ﾞ 6',!　　 / :::::::::::::::/ __
. 　 　 〈　　< ´￣,ﾌ　 .ﾉｰ'_ , ‐'´::::::::::::::;/ （_ノ)‐-､
.　 　 　 ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠.　　 ヽ_}　 ﾞヽ
　 　 　 　 ,.r｀ "´　　／:::::::::::::::::::ィ´　　｀ゝ　 !、　　/
　　　　　/ 　 　 　 / :::::::::::::::: ; '´　　　/´＼　/ 　 r'＼
.　　　　 i　　　　　 ! ::::::::::::::／ 墨　|　.!::::::::／ヽ､.._!ヽ.　ヽ､
　　　　 {　　　　　 {:::::::::::;:ｲ　/　　 ‖ｉ:::::::/:::::::::::::/　 ＼
.　 　 　 ヽ 　 　 　 ヽ,.ｧ‐'´ /ヽ 二 ,/`ヽ、::::::::: ／
0486nobodyさん2009/08/28(金) 04:53:58ID:???
最悪、テンプレートファイルをgrepやsedで一括置換すれば何とかなる。
0487nobodyさん2009/08/28(金) 09:51:01ID:???
とりあえずZend最高
0488nobodyさん2009/08/28(金) 15:24:35ID:???
んじゃ、Zendを活用したCakePHP最高
0489nobodyさん2009/08/28(金) 21:22:50ID:???
他の言語に移行したいけどCakePHPでサイト作るのに慣れすぎて移行できないよ＼(^o^)／
0490nobodyさん2009/08/28(金) 21:29:19ID:???
cakeってちょっと見たけど
1テーブル1コントローラがキモすぎて吐いたわ
どんな顔してあんなの使ってるのか見てみたいものだね
0491nobodyさん2009/08/28(金) 21:47:30ID:???
具体的に1テーブル1コントローラの何がきもいと感じてるの？
柔軟性がなさそうできもいとかそういう感じ？
0492nobodyさん2009/08/28(金) 22:00:20ID:???
コントローラとモデルがくっついてる意味が分からないです・・
コントローラはコントローラ、モデルはモデルだろ・・
0493nobodyさん2009/08/28(金) 22:38:15ID:???
なるほど。
くっついてると言うよりは単に名前を同じようにすることを推奨してる感じかな。
規約上では例えばuserモデルにはusers_controllerを対応させるように、って仕向けてるけど、
そのくっつき感が嫌ならhogefuga_controllerでuserモデルを使用するってこともできる。

なんかうまく書けないな…ごめんなさい
0494nobodyさん2009/08/28(金) 23:05:40ID:???
まあなんというか492がcakeを使いこなせてないのは確実。
0495nobodyさん2009/08/28(金) 23:13:37ID:???
Cakeが、
DB table <-> Model <-> Controller が全て１対１対応になっている
（ように見える）はデフォルトの規約のせい。
実際はどうにでもできるし、また習熟すればModel中心で
開発できるようにもなる。
0496nobodyさん2009/08/29(土) 00:20:46ID:???
最近のフレームワークは肥大化しすぎてて、
PHPの学習コストの低さを完全に打ち消しちゃってるよね。

進化も早いから新人教育が本当に面倒くさい･･･。
0497nobodyさん2009/08/29(土) 01:33:51ID:???
>>496
そもそもお前は考え違いをしてる
フレームワークは素人が使うもんじゃなくて
それなりに習熟した奴が工数を減らすために使うんだ
だから学習コストが必要になるのは当たり前
0498nobodyさん2009/08/29(土) 01:50:29ID:???
そうなの？
工数減らす事より、コーディング品質を上げる為に導入って会社の方が多い気がするけど・・・

規模が大きければ大きいほど、工数の大半はビジネスロジックになるから
フレームワークで減らせる工数なんてたかが知れてない？
逆に無謀なカスタマイズを要求されて、時間と技術を無駄にしている気すらある。
0499nobodyさん2009/08/29(土) 02:08:14ID:???
フレームワークってのはぶっちゃけテンプレートの集合であって
中身と使い方を理解しなければ使い物にならないんだぞ
0500nobodyさん2009/08/29(土) 03:52:12ID:???
よくsymfonyの説明で「このフレームワークは大規模案件にも対応できる！」って書かれてるけど、
具体的にどの辺りが大規模向けなの？コントローラとかのディレクトリが階層状態になってるから
ファイルが多くなっても大丈夫、とかだけじゃないよね？
0501nobodyさん2009/08/29(土) 05:08:19ID:???
>>496
というかFW無しで、それなりの規模でしっかりしたWEBアプリ作れるように新人教育する方が確実に大変だろ・・

>>492
きちんと使ってもいないのに語るのはやめた方がいいよ。
MVCきっちり分かれてるし、自由に切り替え可能。
モデル使わないコントローラーだって当然可能だし。
0502nobodyさん2009/08/29(土) 13:14:13ID:???
>>501
FW使っても設計が出来ないと、大規模開発には耐えられないけどね。
PHP自体をしっかり憶えて、そういう基礎知識を伸ばす方が重要だと思う。
0503nobodyさん2009/08/29(土) 14:41:20ID:???
>>500
規約がかっちりしてるからパラレルに作業しやすいとかかな
0504nobodyさん2009/08/29(土) 14:47:27ID:???
>>503
規約ってどのくらいの範囲まで及んでるのかな？
ディレクトリ名とかファイル名とかクラス名とかDBのテーブル名とか参照できる変数名とかキーの名前くらい？
0505nobodyさん2009/08/29(土) 19:25:33ID:???
>>504
名前じゃなくて中身が本質なんだと思うがｗ

命名規則とかタブ幅とかが書かれたコーディング規約だけじゃなくて、
CoC的な意味での設定とか規約とかも含めた、構造そのものが範囲じゃないかな。

すげーざっくり言うと「コードを書く場所を機能別に分ける」ってことだよ。
ファイルを階層別に分けるのも、命名規則をつけるのも、その目的を果たすためにしたことだ。

個人的には、symfonyが大規模案件に向いているというのはすごく眉唾で、
「PHPの実績あるフレームワークで大規模案件をやるならsymfonyしか選択肢がない」
というのが日本の実情に近いんだと思う。
0506nobodyさん2009/08/29(土) 19:30:32ID:???
それだけ聞くと別にsymfonyじゃなくても良いと思えてしまう。
0507nobodyさん2009/08/29(土) 21:21:47ID:???
勿論、設計がしっかりしてりゃなんだっていいし、別にオレオレフレームワーク作ったって構わないわな
「設計がしっかりしてる」ってのをどこで判断するんだ、って話だ
symfonyに限らず、実際にそのフレームワークで構築された大規模サイトがある、ってのは、大規模な案件になっても設計的に破綻しないという何よりの証明
採用件数が多ければ、トラブルシュートの類も蓄積されてるだろうしな
ユーザー数が多いという事は、本体の開発者も多い事が期待できるし
0508nobodyさん2009/08/30(日) 03:07:06ID:???
日本においてはその限りでは無い気が･･･
0509名無しさん＠そうだ選挙に行こう2009/08/30(日) 04:05:27ID:???
うーんぶっちゃけ、そんなに「開発規模が大きくなる事」とか、
「開発規模が大きくなることを念頭に置かれた設計である事」に魅力を感じるか？
と自分に問うと、自分の場合はそうは思わん。（仕事の面白さ的にも）

ただ「運用していくうえでのスケーラビリティだけは確保しときたいよね」って所と、
コードの見通しの確保、あと万一ソースコードを他者に引き継ぐとかって話になった時に
話が少しだけ早くなる、っていう3点だな。
自分がPHP案件でオープンなアプリケーションフレームワークを利用する意味は、そのくらいだと思う。

まあ、自分みたいなタイプは少ないかもしれん。
もしかしたら結構みんな、多数の人員で多くの人月かける仕事が好きなのかもしれないし。
0510名無しさん＠そうだ選挙に行こう2009/08/30(日) 15:50:15ID:???
>>509
俺は大規模案件に魅力を感じる。
みんな知ってるあのサイト、実は俺俺フレームワークで動いてるんだぜ、
とか言ってみたいものだわ。そういうのに挑戦していきたい。

「Railsもどきを作りましょう」じゃなくて「案件ありき」で作った。
俺がsymfonyをリスペクトしてる理由は、それだけだな。
フレームワークとしてはちっとも高性能でも万能でも無いと思うが、
大規模案件のお手本にするには十分ためになるよ。

あと、微妙に「大規模」の定義がずれてるような気もするｗ
0511名無しさん＠そうだ選挙に行こう2009/08/30(日) 16:08:56ID:???
アクセス規模が大きい、って意味の大規模だと、symfonyやcakeは微妙だな
最終的には素のPHPで必要最小限の処理を手続き的に書くのが最速になる

この場合の「大規模」は、機能数や、エンジニア数（工数）という意味での「大規模」だと思う
0512名無しさん＠そうだ選挙に行こう2009/08/30(日) 16:26:32ID:???
規模がでかいんだったら俺ならJavaにするな
0513名無しさん＠そうだ選挙に行こう2009/08/30(日) 16:46:32ID:???
規模がでかいんだったら俺ならYiiにするな
0514名無しさん＠そうだ選挙に行こう2009/08/30(日) 17:02:32ID:???
yii使ってる人いるの？
0515nobodyさん2009/08/30(日) 20:19:55ID:???
個人的に使い始めてる人はいると思うよ
いろいろ便利
0516nobodyさん2009/08/30(日) 20:21:56ID:???
Javaって共有レンタルサーバーで使えるようになるかな？

もちろん探せば使えるところあるだろうけど、
PHPぐらいにたいてい対応しているレベルになるかなってこと。
0517nobodyさん2009/08/30(日) 20:41:39ID:???
スレ違い
0518nobodyさん2009/08/30(日) 20:53:08ID:???
>>517
うるさい
0519nobodyさん2009/08/30(日) 21:00:01ID:???
スレ違い
0520nobodyさん2009/08/30(日) 21:11:36ID:???
共有鯖で大規模サイトやりたいのか？ｗｗｗ
0521nobodyさん2009/08/30(日) 21:37:54ID:???
スレ違いと言ったらうるさいと言われた。ワロタ
05225092009/08/31(月) 00:45:30ID:???
>>510
>>511
確かに「工数としての大規模」と「アクセスが大規模」の話がこんがらがってるね。
自分が言いたかったのは、前者の意味での大規模に、それほどの面白みを（個人的には）感じないという事。
でも、当然アクセス規模が（意図する・しないにかかわらず）大きくなるような案件には夢を感じる。
そういう時に、後からスケールアウトしやすく設計されているフレームワークを使っておくのはひとつの手だと思う。
最初からDBレプリケーションだのmemcacheだの利用した実装してアクセス全然だったらアチャーって思っちまうし。

話のポイント外してるようだったらごめん

0523nobodyさん2009/08/31(月) 11:01:34ID:???
個人的にはZendみたいなライブラリ集っぽいモノに、
俺俺フレームワークをかぶせるのがベストプラクティスだと思っている。

DBとかセッションとか普遍的なロジックはライブラリ集を使って、
認証やバリデーション、コントローラ/モデルあたりの毎回ロジックに改修が入る部分は、
自分の使いやすい方式で実装するのが良いと思う。


質問スレとかで、自分で書けば数行のものを、むりくりフレームワークを改修して実現しようとしている人を見ると微妙な気持ちになるわ。
0524nobodyさん2009/08/31(月) 11:18:48ID:???
>>523
はげしく同意。
フレームワークを使っても、毎回どっか改造しなきゃいけないところがあって、
なんかフレームワークを使ううまみがかなり減るよなーといつも思う。
0525nobodyさん2009/08/31(月) 11:28:59ID:???
自分ひとりでやるならオレオレでもいいだろう。
けど他人が絡むのであれば、それではまずいだろう。
0526nobodyさん2009/08/31(月) 11:39:25ID:???
>>525
個々がフリーダムにコーディングしてしまうとまずいだろうが、
ある程度の規定を決めて社内フレームワーク的なモノにすればよくね？

仮に特定のフレームワークを導入したとしても、連携とれるかどうかは別だしさ。
むしろ既存フレームワークを誰かがカスタマイズしてしまうと、余計にカオスな状況になる気がする。
0527nobodyさん2009/08/31(月) 11:49:57ID:???
設定ファイルで全て賄おうとする思想のフレームワークが嫌いだ。
大抵、設定ファイルという名の新言語になっている。
0528nobodyさん2009/08/31(月) 11:51:07ID:???
>>526
>むしろ既存フレームワークを誰かがカスタマイズしてしまうと、余計にカオスな状況になる気がする。

ほんとだよ
0529nobodyさん2009/08/31(月) 12:36:19ID:???
> 個々がフリーダムにコーディングしてしまうとまずいだろうが、
> ある程度の規定を決めて社内フレームワーク的なモノにすればよくね？

であれば既存のフレームワークでいいのでは？
なぜ、車輪を再発明してまでFWを自作したい？

よっぽど特殊なドメインのWebシステムで無い限りはそんな必要性ないかと。
0530nobodyさん2009/08/31(月) 12:51:53ID:???
ようするにエンジニアだから。
全部自分で作ってみたいんだよ。
フレームワークみたいなブラックボックスが我慢できないんだよ。
0531nobodyさん2009/08/31(月) 14:23:01ID:???
Cよりアセンブラと思ってた時期もあったな
0532nobodyさん2009/08/31(月) 14:33:19ID:???
FWのソースを見て理解出来ないようなヤツは、
ハナから黙ってそれを使え。
0533nobodyさん2009/08/31(月) 14:54:03ID:???
>>526
結果的に使う人にとっては、同じようなFWになる気がするけど
自社だろうが、既存フレーワークだろうが使用するだけの人にとっては今まで出てきたような問題のメリットもある。

すでに十分な機能の自社フレームワークがあるならいいけど、既存のFWより機能の少ないものを作ってそんなにメリットあるのかな。
速度?でも色々付けたらそんな変わらないんじゃないの?
05345332009/08/31(月) 14:55:14ID:???
>>533
「問題のメリットも」じゃなくて、「問題もメリットも」
でありますw
0535nobodyさん2009/08/31(月) 15:06:09ID:???
>>529
>であれば既存のフレームワークでいいのでは？
おまえさ、もうちょっと話の流れを追ってから書き込もうぜ。
526だけじゃなくて、もうちょっと上の523あたりから読んでみなよ。
既存のフレームワークに問題点を感じているから話がはじまったのに、
「既存のフレームワークでいいのでは？」とはこれいかに。
0536nobodyさん2009/08/31(月) 15:48:00ID:???
> フレームワークを使っても、毎回どっか改造しなきゃいけないところがあって、

っていうか俺今までいろんなフレームワーク使ってきたことがあるが、
フレームワーク自体に手を入れなきゃいけなかったことなんて一度もないんだが。
単に、フレームワークを使いこなせていないだけなのでは？
0537nobodyさん2009/08/31(月) 16:49:29ID:???
FWの設計的に想定外の処理を追加したい場合とかに
大げさなラッパーコードを書かなきゃいけないのが不毛だって話だよね。

てゆーかどんなフレームワーク使ってても、
自然とそれを覆う為の俺俺フレームワーク(クラス群)が出来上がらないか？

>>536
フレームワーク自体は書き換えないだろ･･･
それを覆うコード群が膨大になると結局カオスになる。って事かと。
0538nobodyさん2009/08/31(月) 16:57:10ID:???
>>529
>>533
全てを再発明するわけでは無いよ。
既存フレームワークの設計上、実装が面倒になりそうな部分は、自前で書く方がメリットあるんじゃない？

既存フレームワーク ＋ 自作の使いやすいコンポーネント ＝ 俺俺フレームワーク
0539nobodyさん2009/08/31(月) 17:00:43ID:???
きちんとしたFWでそこまで大きな改修やラッパーが必要になるかな・・
っていうのは同意

特殊なものを作ってるのかもしれないが
0540nobodyさん2009/08/31(月) 17:20:51ID:???
ZendFramework使ってるけど、コアな処理にZend系クラスを直で使ってしまうと後々カスタマイズが出来ないので、
継承クラスや、ラッパーを作って使っている。

普通はするよ・・・ね？
0541nobodyさん2009/08/31(月) 18:16:46ID:???
そもそもZFは使ってないけど、他FWのライブラリとして使ってるという印象。
0542nobodyさん2009/08/31(月) 18:25:43ID:???
こういう種類があるということか。

1. FWなし
2. 100%俺俺FW
3. 100%一般的なFW
4. 一般的なFWの上に、俺俺FW

俺の場合、新しいプロジェクトを作るときは、たいていそれまでに作った
似たようなプロジェクトのコードをテンプレート代わりに使ったりするから、
上の分類だと4ということになるのか？
0543nobodyさん2009/08/31(月) 18:34:18ID:???
>>542
正直1と2はスレ違いな気もするw
0544nobodyさん2009/08/31(月) 20:02:13ID:???
>>540
この意見よく聞くしよく見るけど、実際にラッパーにしといてよかったーって
場面はあまり見たことない。
0545nobodyさん2009/08/31(月) 20:37:26ID:???
実際に使うのは下っ端ですから・・・
0546nobodyさん2009/08/31(月) 20:44:45ID:???
>>544
自分の場合はZFの不具合(日本語系)に悩まされて、パッチとしてラッパー作るようになったｗ
0547nobodyさん2009/08/31(月) 21:01:44ID:???
>>546みたいに問題が起きたり問題が起きそうなクラスだけ
ラップするのは普通だし現実的だと思う

>>540が何でもかんでもとにかくラップするっていう話なら
ちょっと無駄な気はする。まあ、何でもかんでもってことは
さすがにないか
0548nobodyさん2009/08/31(月) 21:22:25ID:???
既存のシステムからのコールを、極力回収や学習をしなくてもいい形にZFにつなぐためのラッパーならも
ありかなと個人的に思う。
学習についてはいろいろあるだろうけど、今まで作ってて結局周りを巻き込んで学習する時間なかったり
するもんで、php4とかで使用してたライブラリのコール仕様になるべく併せた形に書き換えて作ったことは何度かあった。
0549nobodyさん2009/08/31(月) 21:53:21ID:???
>>522
> 後からスケールアウトしやすく設計されているフレームワーク

実際、無いよなあｗ

だから、俺俺フレームワークでラップしてるような気がする。
開発者や開発案件の思想に依存する「俺俺スケール」が先にあるのかも知れない。

やってる事がbug-fixにとどまらず、俺俺部分に意志が入っちゃうんだよね。
>>542の分類で言うなら、
「一般的なFWの上に、俺俺bug-fixを加えただけのもの」
があってもいいはずなのに、なかなかそれだけで改造が終わることが無いｗ
0550nobodyさん2009/09/01(火) 00:17:27ID:???
インスタンス生成部だけ独自実装して素のZend使えばいいんじゃね。
差し迫った必要に迫られても、同じインターフェイスを持つ別のクラスを返すようにすればサクっと入れ替えられるしな。
まあ、DIなわけだが。

俺の場合、PDOのラッパークラスはかなり頻繁に作るな。フレームワークじゃなくて言語組み込みだからちとアレだが。
全メソッド呼び出しを記録できると色々便利。
0551nobodyさん2009/09/01(火) 00:45:04ID:???
DIでいいじゃん
0552nobodyさん2009/09/01(火) 02:31:52ID:???
>>549

＞ >>522
＞ > 後からスケールアウトしやすく設計されているフレームワーク
＞
＞ 実際、無いよなあｗ
＞
お前はFWを使いこなせてないだけ。
0553nobodyさん2009/09/01(火) 08:47:02ID:???
>>552
はいはい僕ちゃんは使いこなせてて凄いでしゅねー
0554nobodyさん2009/09/01(火) 08:56:29ID:???
おまいら仕事しろよ
0555nobodyさん2009/09/01(火) 09:13:31ID:???
>>549は>>522が言ってる「スケールアウト」を勘違いしてそう
05565222009/09/01(火) 15:33:02ID:???
>>549
レスありがとう
自分自身の感覚になってしまうけど、
CakeにしろSymfonyにしろ（この２つしか例に出せないゴメン）、
十分にスケールアウトを考慮した設計になってると思うよ。
でも逆に言えば、サーバ一台で完結させるような場合には、どうしてもオーバーヘッドが出て来るよね

むしろ本当に書き捨てでいいアプリならば、これらを使わずに
「俺俺」や「素のPHP」でもいいと思う。というかむしろそうする。
05575492009/09/02(水) 00:38:03ID:???
>>555
ん？
俺は>>522読んで、（アクセス規模に対する）スケールアウトという言葉の用例が、
DBレプリケーションやmemcacheにかかってるんだと思ってた。

>>556
アクセス規模が増えてDBレプリケーションやmemcacheを使いたくなった時に、
Cakeやsymfonyだと簡単に移行できるかどうかって話だよね？

>>511と同じく、個人的にはそうは思えなかったけど、改めて調べてみると、
CakeではDBレプリケーション対応は簡単みたいだね。Propel13はダメだ（反論求む）
それに後付けのmemcache対応はどっちでも難しい。（反論求む）
sfSuperCacheも後付けで使うには設計を直す必要があるし（反論求む）
URIの変更もsfRouteやroutesだけの設定じゃ厳しい（ずれてる？）
0558nobodyさん2009/09/02(水) 01:52:53ID:???
PHP最高（反論求む）
0559nobodyさん2009/09/02(水) 02:17:44ID:???
>>557

ZendFWを勉強してみたら良い。君の言う問題は全て解決する。
0560nobodyさん2009/09/02(水) 02:55:20ID:???
ZFは他のFWに比べると書くコード量が一回り増えるけどなｗ
0561nobodyさん2009/09/02(水) 02:57:03ID:???
>>560
そこがFWとして魅力を感じないよね・・
CakePHPのライブラリとして使うと結構その辺を補えるという話を聞くけど
0562nobodyさん2009/09/02(水) 03:48:50ID:???
memcacheなんてもともとシンプルなんだから自分でクラス書けばすぐじゃん
dbの分散化対応は面倒くさいけど
0563nobodyさん2009/09/02(水) 03:50:53ID:???
memcacheってほんの数行のサンプルコードしかみてないんだけど
たんに良くあるキャッシュコードでファイルに保存する代わりに
メモリに保存してるだけだろ？
0564nobodyさん2009/09/02(水) 07:49:25ID:???
PHPってやっぱりドイツの普及率が一番低いのかな？
ドイツ発のフレームワークってないし
0565nobodyさん2009/09/02(水) 08:50:15ID:???
イギリス発とかフランス発とかのフレームワークなんてあるのかい？
0566nobodyさん2009/09/02(水) 08:53:58ID:???
フレームワークは全部韓国発ですよ？
0567nobodyさん2009/09/02(水) 08:54:57ID:???
symfonyはフランス発だよ
0568nobodyさん2009/09/02(水) 08:59:30ID:???
ドイツ発PHPフレームワーク誕生！その名もadolf
05695492009/09/02(水) 11:30:11ID:???
>>559
kwsk

>>562
DBレプリケーションも、それ前提で自作すりゃ簡単だろうさ。
memcacheもそうで、key-value型のホルダを先に作っておけば移行は容易。

でもmemcacheでやりたい事がテーブルやクエリ結果のキャッシュだったら、
それはフレームワーク備え付けのDBアクセス手段じゃ実現困難だよねって話。
0570nobodyさん2009/09/05(土) 05:37:36ID:HKGmqHHH
CakePHPでSQLite3ドライバ使って、
日記サイトみたいなの作ってるんだけど
なんかJOINの結果が変。
他のDBに切り替えようと探してたらPosqlていうドライバ見つけた。
これけっこうｲｲｶﾓ。
SQLダンプからインポートして今のとこ順調。
0571nobodyさん2009/09/05(土) 10:54:07ID:???
>>569

>でもmemcacheでやりたい事がテーブルやクエリ結果のキャッシュだったら、
>それはフレームワーク備え付けのDBアクセス手段じゃ実現困難だよねって話。

>>562は、この点↑を含めて、既存のDBアクセス周りをラップする
クラスを作ればいいんじゃね？って言ってるんだと思うぞ

それに何でもかんでもmemcache頼みってのもどうかと思うぞ
DB周りのメモリチューニングとか、あるいはオンメモリDBを使うとか
その辺は検討したのか？
05725222009/09/05(土) 12:55:50ID:???
>>571

> それに何でもかんでもmemcache頼みってのもどうかと思うぞ

ごめん、memcacheの話は自分が最初に振っちゃったので、
>>549 (>>569)関係ない。
自分は>>549 (>>557) 読んで、まあ確かに、config書き換えですぐに対応出来る訳ではないよなーと
思った。
0573nobodyさん2009/09/05(土) 15:47:56ID:???
もうそろそろkey-value方式の
フレームワークが出ても良いと思うんだ。
0574nobodyさん2009/09/05(土) 17:06:17ID:???
>>573
普通にCakePHPは対応してるでしょ
0575nobodyさん2009/09/05(土) 17:08:00ID:???
違うか普通にキャッシュとして対応してるのか
0576nobodyさん2009/09/05(土) 17:51:14ID:???
>>575
そういうこと。

キャッシュではなくモデルがkey-valueを基礎としているフレームワーク

O/Rつかってリレーショナルなデータをオブジェクトに変換するより
楽じゃないかと思うけどな。

ストレージとして、barkleyDBのようなkey-valueなデータベースだけじゃなく
ファイルやRDBにも格納できる設計で。
05775492009/09/06(日) 02:19:24ID:???
>>571
> 既存のDBアクセス周りをラップするクラスを作ればいいんじゃね？

DBの結果セットをmemcachedに移行するというアプローチは、
自分でやった時はうまくいかなかったなあ。
結局、ご指摘の通りにオンメモリにして逃げちゃった。

なので、簡単に後付けで移行出来る方法があるなら良いなぁと思ったし、
無いんでないかなーと>>549で言っちゃった。

>>573-576
東京なんちゃら対応のなんちゃらモジュールがCakePHPで動くらしいね。
Cakeはよくよく調べてみるとみんなで結構何とかしちゃってる感がある。
0578nobodyさん2009/09/06(日) 16:08:50ID:55qWNNES
チャットプログラム作ってって言われた。相手はシロートさん＆レンタルサーバってコトで、PerlかPHPの二択にほぼ決定。
Perlは正直「使える」程度なんでPHPにしようと思うんだが、Pearを使わないでファイルコピーで設置完了することが可能なFWってあるかな？
一応SymfonyはSandbox使えば可能なのは知ってるが、流石に少々重たいかと思ってね。

・・・ま、「チャットごとき素のPHPで書けよ」ってのは御説ごもっともなんだがｗ、
どうもバリデータやHTML／SQLサニタイズを手で書くのは億劫になってね。
FWに慣れすぎたかもｗ
0579nobodyさん2009/09/06(日) 16:39:56ID:???
FWに慣れすぎた人の質問とは思えないｗ
0580nobodyさん2009/09/06(日) 16:53:37ID:???
もしかしてPEARしか触ったことないんじゃ？
0581nobodyさん2009/09/06(日) 16:54:07ID:???
>>578
いまどき PEAR 使う FW はない
簡単なプログラムなら CodeIgniter でいいんじゃない？
0582nobodyさん2009/09/06(日) 17:02:52ID:???
PEAR(笑)
smarty(笑)
0583nobodyさん2009/09/06(日) 17:13:23ID:???
ちいたんで萌え萌えチャットを（ｒｙ
0584nobodyさん2009/09/06(日) 17:41:33ID:???
>>578
ぜったい釣りだろ、お前w
0585nobodyさん2009/09/06(日) 17:53:04ID:???
あまりにもトンチンカンな PHP 知識。dankogai 疑惑。
0586nobodyさん2009/09/06(日) 17:53:38ID:???
lol
0587nobodyさん2009/09/06(日) 20:33:41ID:???
どうせ個人的に使うチャットだろうし
全部１クラスにまとめたようなレトロな作りにしても十分じゃね
FTPでアップロードして権限振ったらすぐ使えます、のほうがいいような相手なんでしょ

大体バリデーションつっても、入力文字の<>&あたり置換すりゃ早々問題なんて起きんだろうし
ログだってファイルにはいていいんじゃね、小一時間もありゃ書けるでしょ

つか、578の場合レンタルでも探したほうがいいんじゃねｗ
そっちのほうが間違いなく多機能で安全で優れてるとおもうぞ
0588nobodyさん2009/09/06(日) 20:54:55ID:???
>578
fitzgerald。本体が269行しかない。
ttp://www.moongift.jp/2009/06/fitzgerald/
バリデータは存在しないので自分で書かんといけないが。
一番面倒な、入力を一括してフィルタリングする機構はあるのでさほどの手間はない。

あと、エスケープ/サニタイズが面倒なのはお前が阿呆なだけ。
面倒ならエスケープしてからビューに渡す関数とか作れよ。
0589nobodyさん2009/09/06(日) 21:47:35ID:???
関数を作るのもめんどくせえー
0590nobodyさん2009/09/06(日) 22:56:49ID:???
まともなプログラマなら、小規模用の俺俺ライブラリくらい持ってるだろｗ
FWに慣れたっつーより、FWが無ければ何も出来ないの間違いじゃね？

正規表現とかもかけないんじゃね？ｗ
0591nobodyさん2009/09/06(日) 23:09:44ID:???
「相手はシロートさん」にﾜﾛﾀ
おめーも大差ないですよっと
0592nobodyさん2009/09/06(日) 23:30:43ID:???
PHP使いにまともなプログラマっているの？
0593nobodyさん2009/09/06(日) 23:52:14ID:???
いるわけねーだろ
0594nobodyさん2009/09/06(日) 23:58:14ID:???
まともという言葉がどこをさすのかによるだろうな
0595nobodyさん2009/09/07(月) 00:25:40ID:???
何度目だよ
0596nobodyさん2009/09/07(月) 00:36:51ID:???
Regexクラスとかできちゃいそうだよね
0597nobodyさん2009/09/07(月) 02:36:55ID:???
まともなプログラマは言語に依存せず、要件に見合ったコードを書く
PHPかどうかは関係無いし、PHPにも職人クラスのPGはいる。


ただ勘違いした「シロートさん」比率が、他の言語より圧倒的に多いｗｗ
0598nobodyさん2009/09/07(月) 03:31:50ID:???
Pealのにわかプログラマに比べればまだマシだけどな
0599nobodyさん2009/09/07(月) 03:46:45ID:???
PHPはどうしても冗長だからな。
0600nobodyさん2009/09/07(月) 04:43:15ID:???
PHPは取っつきやすいからな。
で、上達するに連れ、言語仕様に不満が出てくる。
そして、他の言語へ移る。

Web用言語の登竜門みたいなもんだから、仕方ないべ。
今更Perlから入る人も少ないでしょうし。

グローバル関数をクラスライブラリ化して、型宣言もアリにして、
OO言語に生まれかわらんかな。

既存のグローバル関数で発生したエラーを例外処理化したライブラリはないかな?
0601nobodyさん2009/09/07(月) 05:04:58ID:???
WEBの基礎知識をすっ飛ばしちゃうから
登竜門としては Perl/CGI の方が良いと思うけどなぁ。

PHPから始めた人て、HTTP通信のバックエンドや、文字コードを理解して無い人が多いよね
multipartなPOSTデータをパースしたり、URLエンコード/デコードしたり、クッキーやセッションの仕組みを理解してなかったり、etc

バグが発生した時に、原因の切り分けが出来なくて困ってる人をよく見る。
0602nobodyさん2009/09/07(月) 05:20:04ID:???
それは言語関係ないと思うけどな

俺はPHPからだったけどWebカメラいじりたくてソケットから弄りだした
まぁその前がC/C++だったから、文字列の扱いが超簡単で楽だったなぁ
0603nobodyさん2009/09/07(月) 06:41:11ID:???
変数のスコープが関数単位だから、処理を局所化したコードの書き方が身につかない。
0604nobodyさん2009/09/07(月) 10:46:40ID:???
>>603
前半と後半のつながりがさっぱりわからん
0605nobodyさん2009/09/07(月) 10:53:21ID:???
PHPしか知らないとそうなる。
0606nobodyさん2009/09/07(月) 11:26:17ID:???
関数内でさらに局所かしたいってこと？
確かにできたほうがいいけど、関数をあまり巨大化させなければそれほど問題にならないのでは？
PHPのだめな所はもっと他にあるだろ
0607nobodyさん2009/09/07(月) 11:34:03ID:???
たぶん、複数の関連性の強い関数群と、それらの間だけで欲しいデータとかのこと言ってるんじゃ
ないかな、603は。
PHPだとそれらを別ファイル分けて書いて見通しだけは良くしても、結局includeだから同一ソース
ファイルに全部放り込んでるのと変わらん、データの独立性が…とか言いたいのかも。

まあ、クラス使えばいいと思うけど、そういうのは。
0608nobodyさん2009/09/07(月) 11:42:30ID:???
603はクラスも知らん子ということですか。
0609nobodyさん2009/09/07(月) 12:08:07ID:???
CやPerlと同じ。書き手の裁量が大きい。
つまり糞がかけば糞になる程度がやや大きい。

その程度の話なんだが言語やOSの話になると痛いのがわんさか沸いてくる。
0610nobodyさん2009/09/07(月) 18:10:57ID:???
みんな喧嘩すんなよ
0611nobodyさん2009/09/07(月) 19:14:09ID:???
スコープが関数単位なのって、PHPとJavaScriptぐらいなものなんだ。もっともJavaScriptですら新しいバージョンじゃブロックスコープになるが。
0612nobodyさん2009/09/07(月) 21:03:02ID:???
>>611
> スコープが関数単位
今まで知らなかったよ。
今までのいろんな謎が一気に解けた。ありがとう。
0613nobodyさん2009/09/07(月) 21:10:03ID:???
array array array array がめんどくさい
0614nobodyさん2009/09/07(月) 21:40:15ID:???
>>612
えっ？なんだと思ってたの？
0615nobodyさん2009/09/07(月) 23:23:59ID:???
>607がアホだという事は分かった。

俺も関数を短くするタイプだから、ブロックスコープはあまり必要性を感じないな。
ブロックの中が10行超えたら大抵メソッド化しちまうから特に困らん。
勿論ブロックスコープが悪いとは思わんが、初心者の学習コストを上げるほどのメリットを感じない。
0616nobodyさん2009/09/07(月) 23:26:06ID:???
ブロックスコープってそんなにいいの？何か効果が分かる例出して
0617nobodyさん2009/09/07(月) 23:40:34ID:???
行の長さに応じてメソッド化するとか意味不明すぎる
0618nobodyさん2009/09/07(月) 23:44:47ID:???
だいたい1メソッド20行超えるようだったら能毎分割できるだろう、
とかみたいな目安の話じゃろ。わりとよく聞く話だとおもうけど
0619nobodyさん2009/09/07(月) 23:57:18ID:???
むしろ、途中で変数宣言するとかの方がおかしいと思うのだが
全部関数の初めでやればいいじゃん。
0620nobodyさん2009/09/08(火) 00:02:55ID:???
それもなんだかなぁ
0621nobodyさん2009/09/08(火) 00:06:12ID:???
関数の最初に全部ってのは廃れたやり方だな
0622nobodyさん2009/09/08(火) 00:08:19ID:???
最初に宣言しないと用途わからなくなるくらい冗長ってことだしなぁ
0623nobodyさん2009/09/08(火) 00:11:52ID:???
>>621
そうなの？
じゃあ流行のやり方はどうなってんの？
0624nobodyさん2009/09/08(火) 00:23:20ID:???
>>623
自分は処理毎の先頭で纏めて初期化している。

意識して関数の先頭で全て宣言する事もあるけど、
あまりメリットを感じない。
0625nobodyさん2009/09/08(火) 00:31:02ID:???
途中で宣言するのは for文とか、カウント系だけかな
あとは全部頭で初期化してる
0626nobodyさん2009/09/08(火) 00:33:15ID:???
クラスプロパティとかは頭におくけど、
メソッド内のローカル変数なんて必要になったら宣言すりゃいいんじゃね
よほど長ったらしい関数とかを書くとかじゃない限り分けて宣言するメリットなくね
0627nobodyさん2009/09/08(火) 00:33:52ID:???
条件によって途中で関数を抜けるような場合は、頭で初期化してしまうと無駄な気分に･･･
宣言と初期化分ければそんなに気にならないけど、あまり意味は無い気もするし。


// $hoge を使わない場合がある。
function hoge()
{
$hoge = new Hoge();
if (xxxx) return;
$hoge->hogehoge();
}
0628nobodyさん2009/09/08(火) 00:41:51ID:???
普通はifとかwhileとかのブロックの中でしか使わない変数は、そのブロックの中で宣言するんだよ。
が、PHPの場合、関数の最初の方で宣言しとくのが分かりやすいと言えば分かりやすい。
が、そうすると変数名の衝突が起きやすいので、長い変数名を使わざるを得ない。よって、記述が冗長になる。
0629nobodyさん2009/09/08(火) 00:41:55ID:???
ブロックスコープ無いってことは、関数呼び出すときに変数を全部初期化してるんじゃないの？
何かそんな資料を昔見たようなうる覚え
0630nobodyさん2009/09/08(火) 00:42:18ID:???
お前らそろそろスレ違いに気付け
0631nobodyさん2009/09/08(火) 00:53:55ID:???
はぁい
0632nobodyさん2009/09/08(火) 00:57:15ID:???
全部グローバル変数にするのが一番かっこいい書き方
0633nobodyさん2009/09/08(火) 01:19:29ID:???
C言語って関数スコープだっけ？ ブロックスコープだっけ？
0634nobodyさん2009/09/08(火) 01:27:39ID:???
Cはブロックスコープ
0635nobodyさん2009/09/08(火) 01:28:50ID:???
ググレカス。
0636nobodyさん2009/09/08(火) 08:10:48ID:???
全部関数の先頭で宣言するとか、VBじゃあるまいしｗ
0637nobodyさん2009/09/08(火) 08:46:05ID:???
このスレって、伸びてるなと思って覗いたら、フレームワークとは
全く関係ない話題で埋め尽くされてることが多いよな。
相応しいスレはいくらでもあるんだから、そっちでやれや。
0638nobodyさん2009/09/08(火) 08:57:46ID:???
そういやVBもブロックスコープじゃなくって、関数単位だったな。VB.NETはブロックスコープになったんだっけ。
0639nobodyさん2009/09/08(火) 11:39:27ID:???
>>611
>スコープが関数単位なのって、PHPとJavaScriptぐらいなものなんだ。？x2028;ダウト。
変数宣言のない言語はたいてい関数スコープ。PythonもRubyもそう。
06405782009/09/08(火) 12:25:14ID:???
お返事が遅くなって申し訳ない。
・・・まぁ、この流れはある程度想定の範囲内。
フツー、「んなもんスクラッチで書けよ」って思うよなｗ

>>587
相手についての考察は大体そのとおり。だからpear使いたくなかったんよ。
レンタルチャットでは多分無理。少なくともかなりのカスタマイズしないといけないんで、結局手間はあんまり変わらないと思われ。

>>588
これは知らなかった。ORマッパ無しというのもいいかも。
少し調べてみるっす。感謝＞fitzgerald

エスケープ/サニタイズは、まぁPHPは結構便利な関数があるからそんなに面倒ではないんだけどね。
ま、>>578のとおり、そんなにがっちり組む必要もないんだし、
>大体バリデーションつっても、入力文字の<>&あたり置換すりゃ早々問題なんて起きんだろうし
>ログだってファイルにはいていいんじゃね、小一時間もありゃ書けるでしょ
でいいっちゃいいと思うんだがね。

>>590
あることぁあるが、PHP4の時代のヤツなんでねぇｗ＞俺俺ライブラリ
ま、正規表現は確かに苦手だ。eregとpregでビミョーに違うのもややこしいしｗ
0641nobodyさん2009/09/08(火) 12:31:29ID:???
>>639
Rubyはブロックスコープだが。
0642nobodyさん2009/09/08(火) 18:43:17ID:???
どのフレームワークのコーディングがきれい?
0643nobodyさん2009/09/08(火) 19:28:03ID:???
>>642
好みが大きいと思うけど、標準的なPHPという点ではZFかな？
0644nobodyさん2009/09/08(火) 19:41:42ID:???
ZFはコーディング規約の為のFWと言っても過言では無いからなｗ
0645nobodyさん2009/09/08(火) 19:42:43ID:???
あぁ、クエリを弄れる人がいないのか
06466452009/09/08(火) 19:44:11ID:???
誤爆スマソ。
0647nobodyさん2009/09/09(水) 02:15:12ID:???
>>627
その例は設計が悪い
0648nobodyさん2009/09/09(水) 03:38:43ID:???
>>647
具体的に何が？割とよくあるコードだと思うけど？
return に限らず throw　とかも含めてね。
0649nobodyさん2009/09/09(水) 04:07:50ID:???
使わないのなら関数で処理分けろよ
バグの温床じゃん
0650nobodyさん2009/09/09(水) 04:39:08ID:???
バリデーションとか含めるとどうしても >>627 みたいなコードは発生するよ。

A処理、B処理、C処理を連続して順番に処理する事を保証する場合、
内部的にメソッドを分けたとしても、PGに提供するメソッドは一つにするのが普通だろ。
その場合、途中の処理でこけた場合、どの処理でこけたかを判断する為に、return もしくは throw 等を使う。

それをしない方がバグの温床になると思うんだが･･･
0651nobodyさん2009/09/09(水) 04:49:10ID:???
変数の宣言とクラスの宣言を混同してる件について
0652nobodyさん2009/09/09(水) 04:55:14ID:???
ん？どこが？
0653nobodyさん2009/09/09(水) 05:02:31ID:???
あぁ >>651 は宣言と初期化の区別がつかないのかｗ

クラスの宣言ってのは、通常 class Hoge {} な構文を指す言葉だから誤用しないようにね。
0654nobodyさん2009/09/09(水) 05:02:56ID:???
宣言っつーか初期化だろ、Warningでるやつ

1ヶ月でログが20GB超えてたときは流石に吹いたわ
0655nobodyさん2009/09/09(水) 05:06:12ID:???
>>654
あるあるｗ　と言いたいが、途中で気がつけよｗ
0656nobodyさん2009/09/09(水) 05:18:47ID:???
ローテーションして圧縮してたから、まったく気づかなかった
書庫の中身見てはじめて気づいたんだわ

写真とかアップロードするから、容量に関しては無頓着だったし
0657nobodyさん2009/09/09(水) 05:23:06ID:???
mooseのlazyみたいなのがあればいいんだけどな。
0658nobodyさん2009/09/09(水) 05:30:56ID:???
Mooseのｌａｚｙって、内部的にはどんな実装になってるの？
0659nobodyさん2009/09/09(水) 07:00:39ID:???
>>656
稼働前にdisplay_errorsオンにするなり、error_reportingなりでデバッグしないの？
活用しないログほど意味の無いものは無い。
0660nobodyさん2009/09/09(水) 08:27:51ID:???
お前らいい加減スレ違いに気付け
0661nobodyさん2009/09/09(水) 08:41:34ID:???
フレームワークに限らないPHP全般について、うだうだやるのに適切なスレはどこでしょうか。
0662nobodyさん2009/09/09(水) 09:08:54ID:???
くだ質か雑談あたりじゃね
0663nobodyさん2009/09/09(水) 17:32:08ID:???
フレームワークの設定ファイルってどんな感じがいいの？

・xmlとかでphpソースと別ファイルにする
・phpソースに定数とか連想配列で保存

0664nobodyさん2009/09/09(水) 17:34:01ID:???
どっちでも便利なほうでいいんじゃ？
0665nobodyさん2009/09/09(水) 18:14:09ID:???
>>663
YAMLいいよ、YAML
0666nobodyさん2009/09/09(水) 18:23:52ID:???
xmlよりは扱いやすいよね。
0667nobodyさん2009/09/09(水) 18:46:02ID:???
俺もYamlで別ファイル
06686632009/09/09(水) 18:55:08ID:???
YAMLですか。
勉強してきます。
0669nobodyさん2009/09/09(水) 21:36:02ID:???
そこでJSONですよ
0670nobodyさん2009/09/09(水) 23:12:42ID:???
JSON の IE 対策の最後の , が保守性低い
0671nobodyさん2009/09/09(水) 23:45:11ID:???
JSONはYAMLに比べたら人間が書きにくい。読みにくい。わかっていて言っているんだと思うけど。
以下のヤツは俺が使っている設定ファイル・・・を参考に書き直したもの。
ただのコメントが入った設定ファイルように見えるが、これがYAMLの文法なんだぜ。

# 各種プログラムのパス
bin:
　sendmail: '/usr/sbin/sendmail'
　nkf: '/usr/bin/nkf'

# テンポラリディレクトリ
tmp: '/tmp'

cache:
　# キャッシュディレクトリ
　dir: "/var/www/html/myapp/cache"

　# キャッシュの保持時間(秒)
　expires: 604800 # 1 week
0672nobodyさん2009/09/09(水) 23:47:08ID:???
YAMLの公式サイト
http://www.yaml.org/



↑YAMLで書かれていますｗ
0673nobodyさん2009/09/09(水) 23:52:12ID:???
そうか？YAMLだと空白とか訳分からんミスでエラーに
なったりする時があるから、JSONの方が好きなんだが。

プログラマならJSONの方が構造が直感的に分かると思うんだが。

一般人の理解しやすさは
YAML > JSON >>>>>>>>>>>>>> XML

プログラムからのいじりやすさは
JSON > YAML >>>>>>>>>>>>>> XML

という感じだと思うんだが。

あと記述する内容によって適したデータ形式があるから
プロジェクトごとに選択するしかないと思う。
0674nobodyさん2009/09/10(木) 00:02:10ID:???
俺としては一番理解しやすいのは ini なんだけど。
PHPの関数も用意されてるし
0675nobodyさん2009/09/10(木) 00:21:48ID:???
俺の場合JSも頻繁に触るから、確実に覚えているJSONの方が都合がいい
YAMLの可読性は素晴らしいとは思うけど、適度に記号入ってた方が好み
0676nobodyさん2009/09/10(木) 00:28:49ID:???
>>673
JSONにコメントないじゃん。

プログラムが受け渡すデータならJSONでいいけど、
人間が読み書きするならYAMLの方が良いよ。

あと必要ならデータ形式は変換すれば良いだけ。
0677nobodyさん2009/09/10(木) 00:31:57ID:???
あとキーが文字列なので、""で括って、"key":123としないといけないのもちょっといただけない。
0678nobodyさん2009/09/10(木) 00:43:06ID:???
単純な設定ならiniファイルかな･･･
複雑な設定ってWEBプログラムではそうそう無いと思うけど。

バリデーションルールを無理矢理YAML化してるの見ると、なんだかなぁと思う。
06796692009/09/10(木) 00:44:44ID:???
やべ俺シャレで書いたつもりだったのにマジでJSONをconfigに使う人いたんだｗ

YAMLは３年ほど前spycを使ってとり回そうとして挙動不審だったのでいい思い出がない。
みんなYAMLのパーサ何使ってるの？syck? spyc? preg使って自前?
その辺でおすすめあればもう一度トライしてみます。
0680nobodyさん2009/09/10(木) 01:00:39ID:???
spyc使っているけど、なんか問題ある？
なんか問題あったとして、今は修正されたんじゃない？

と思って今見てみたら、0.4.2がでてる。
パフォーマンス向上とな。入れ替えようｗ
0681nobodyさん2009/09/10(木) 01:21:40ID:???
データとして扱うもんならJSON使ってるなってか
フレームワークどころかPHPですらなくなってるぞ
0682nobodyさん2009/09/10(木) 08:30:09ID:???
PHPのフレームワークに詳しいみんなは、ハンバーグ作る時って
牛肉と豚肉の割合どのくらいにしてる？
0683nobodyさん2009/09/10(木) 09:09:16ID:???
俺もわけわからんエラー出たことあってphpでyaml使うのは好きじゃない
0684nobodyさん2009/09/10(木) 10:01:32ID:???
>>683
今安定してるよ
PEARのやつもあるし
0685nobodyさん2009/09/10(木) 10:16:04ID:???
syck と spyc で YAML の互換性がないのはもう直ったの？
あと、YAML ファイルがでかいと解析時間も遅いのが問題。
0686nobodyさん2009/09/10(木) 11:23:12ID:???
キャシュしないの?
0687nobodyさん2009/09/10(木) 12:08:36ID:???
iniかXMLで十分じゃね？

XMLなら内容の不備も事前に見つけられるし・・・
0688nobodyさん2009/09/10(木) 12:21:27ID:???
中身が一本のarrayでいいならserializeもいいかも。
0689nobodyさん2009/09/10(木) 13:05:12ID:???
>>686
初回の立ち上がりの遅さが気になって
0690nobodyさん2009/09/10(木) 20:08:02ID:???
YAMLの遅さが気になる場合は、
serialize/unserializeしてキャッシュするだろ？

設定ファイルなんて頻繁に変更するわけじゃあるまいし。
0691nobodyさん2009/09/10(木) 20:20:36ID:???
たかが設定ファイルのためにキャッシュ機構を組み込むほど
yamlの利便性>>>arrayなのか？という問題は難しいところ
0692nobodyさん2009/09/10(木) 20:21:35ID:???
ここで普通にPHPファイルでイイじゃんとか言ったら叩かれますかw
0693nobodyさん2009/09/10(木) 20:30:02ID:???
>>692
いいんじゃないかｗ

俺はINIファイル派だけどなｗ
0694nobodyさん2009/09/10(木) 20:59:40ID:???
スタティクファイル読み込みクラスのアダプターとしてYAML読み込みを実装
0695nobodyさん2009/09/10(木) 21:04:31ID:???
yamlっつっても、symfonyの設定ファイルみたいに、
そこにphpコードも書けないと不便だよね
そういうことを考えていくと余計に面倒になってくる
フレームワークに元々実装してあるなら使うけど
0696nobodyさん2009/09/10(木) 21:25:53ID:???
PHPネイティブでiniやXMLがあるのに、YAMLを選択する理由がわからんなぁ･･･。

iniはシンプルかつ、一般的。
XMLは複雑だが、Flash等と親和性がある(扱えるデザイナが多い/開発環境も多い)
JSONはJSとの親和性がある

YAMLは学習及び実装コストに見合うメリットはあるのだろうか？
ミーハーな感じがするわ。
0697nobodyさん2009/09/10(木) 21:35:20ID:???
JSONより楽ちんなところくらいかな
0698nobodyさん2009/09/10(木) 21:42:33ID:???
学習コスト、実装コストってwwww

そんなもん一時間かそこらだろうが。試すだけ試してみりゃいいじゃん。
0699nobodyさん2009/09/10(木) 22:21:24ID:???
PHPで完結してるならYAMLなんて使わず素のPHPでいいと思う。順番付のハッシュがある（しかない）PHPの変数構造体は十分分かりやすいと思う。
0700nobodyさん2009/09/10(木) 22:34:09ID:???
YAMLは半角スペースで階層を表現してる時点でなぁ･･･
意図しない半角スペースが入っていても値としては正常なモノとして扱われるのが厄介すぎる。

>>698
パーサからの実装を1時間そこらで出来るわけないだろｗ
0701nobodyさん2009/09/10(木) 22:38:25ID:???
すでに実装があるから必要ないだろ。
0702nobodyさん2009/09/10(木) 22:38:41ID:???
>>696
iniはセクションがどうとか、データの階層構造で
複雑なものが作れないんだわ。

YAMLだと自分が思ったままの理想のデータ構造そのまま定義できる。
楽なんだよ。

＞＞699
array( array( array( 地獄から抜け出せるぜｗ
0703nobodyさん2009/09/10(木) 22:46:53ID:???
arrayの表記がダサいのが一番問題なんだよな
[]とかで表記できたらいいのに
5.3もおもしろ機能ばっかり付けないでそういうの付けろ
0704nobodyさん2009/09/10(木) 22:49:13ID:???
>>701
どこの誰が作ったかもわからん実装を検証もせず使えるかｗ
0705nobodyさん2009/09/10(木) 22:51:08ID:???
>>704
OSから作ってんのか？ それともCPUも？
0706nobodyさん2009/09/10(木) 23:08:51ID:???
>704
じゃあ検証すりゃいいじゃん
少なくとも自分で書くよりは速いぜ
0707nobodyさん2009/09/10(木) 23:21:30ID:???
>>704
PHPも自作なのか
0708nobodyさん2009/09/10(木) 23:28:45ID:???
天才の704さんがぱねぇっす。
もちろん他人の作った飯なんて、米なんてのも食べられないんですよね？
0709nobodyさん2009/09/10(木) 23:38:01ID:???
>>703
はげどうだわｗ
0710nobodyさん2009/09/10(木) 23:45:09ID:???
配列と連想配列の組み合わせとかarrayarrayarrayarrayで書いてて頭がおかしくなる
0711nobodyさん2009/09/10(木) 23:58:39ID:???
arrayarrayarrayって書いていると、頭がおかしくなって、あ〜りぃ〜？って言う。
0712nobodyさん2009/09/11(金) 00:05:00ID:???
drupal 使っていると、array の array の array の array の array
とか当たり前で目が痛くなってくるｗ
0713nobodyさん2009/09/11(金) 00:06:27ID:???
>710
function a(){
return func_get_args();
}
というのはどうだろう、今思いついたんで動くかは知らん
0714nobodyさん2009/09/11(金) 00:06:48ID:???
有野有野有野うるさいんだよ。お前は有野のなんなんだ！
0715nobodyさん2009/09/11(金) 00:41:38ID:???
>>713
a('h' => 'o')
07167132009/09/11(金) 02:39:35ID:???
>715
連想配列は配列ではない(ｷﾘｯ
…正直すまんかった
0717nobodyさん2009/09/11(金) 02:57:51ID:???
PHPの場合、連想配列と配列の区別ってないだろ
0718nobodyさん2009/09/11(金) 05:32:45ID:P+LwJJ6C
>>699
納品先によっては、ソースを直すには抵抗あるけど設定ファイルならOKってところもあるな。
0719nobodyさん2009/09/11(金) 05:39:23ID:???
OSやPHPの実装と、YAMLパーサの実装を同じ視点で考えちゃうのか･･･YAML信者は怖いな。
YAMLがメジャーになりうる要素も気配も無いのにね。
0720nobodyさん2009/09/11(金) 09:11:44ID:???
> YAMLがメジャーになりうる要素も気配も無いのにね。

え？ すでにメジャー・・・
0721nobodyさん2009/09/11(金) 09:14:37ID:???
何を根拠に
0722nobodyさん2009/09/11(金) 09:17:21ID:???
> え？ すでにメジャー・・・
YAML厨乙ｗｗｗ
0723nobodyさん2009/09/11(金) 09:54:42ID:???
array arrayに嫌気がさしたらqiq
0724nobodyさん2009/09/11(金) 09:58:21ID:???
qiq は壊れた go-pear.phar や php_pgsql.dll なんかも修正した ( Linux であるような ) ディストリビューションとして配布されてもいいと思う
0725nobodyさん2009/09/11(金) 10:28:02ID:???
<自分語り>
とりあえずアンテナ低目の俺の場合、

ini, XML, JSON: ここしばらくの話は分かる程度には知ってた。
YAML: 「え、なにそれ?」とぐぐった
</自分語り>
0726nobodyさん2009/09/11(金) 11:46:22ID:???
正直設定ファイルごときにパーサ用意するのがめんどい
男は黙ってconfig.inc.php
どうせパスの位置ぐらいしか設定しないから配列地獄とは無縁
0727nobodyさん2009/09/11(金) 15:20:54ID:???
スタティクな値のビューへのアサインに使ってる
0728nobodyさん2009/09/12(土) 01:26:50ID:???
パスの設定しかしない人はconfig.inc.phpで問題ないだろう
0729nobodyさん2009/09/12(土) 03:11:18ID:???
そこまで変更ぐりんぐりんやらないといけないようなもの作るときにPHP選択しないん
0730nobodyさん2009/09/12(土) 13:48:16ID:???
そもそも、変更ぐりんぐりんやることあるのか？
0731nobodyさん2009/09/12(土) 15:53:14ID:???
そんあことは少ないし、そういう要件あっても、
フレームワークごとに推奨する実装あるだろ。
0732nobodyさん2009/09/13(日) 00:43:11ID:???
そんなに書き換えることもないような設定のためにわざわざパーサ用意するくらいなら
array(array(でいいよ
0733nobodyさん2009/09/13(日) 01:36:36ID:???
ZendFWのドットシンタックスなiniファイルで十分。

db.host = xxxx
db.user = xxxx
db.pass = xxxx

複雑な階層構造を持つ設定なんてそうそう無い。
設定ファイルドリブンな思考はためるべき。
0734nobodyさん2009/09/13(日) 01:40:40ID:???
xxx.iniってファイル名で、中身はPHPでいいよ
0735nobodyさん2009/09/13(日) 01:51:06ID:???
設定ファイルにPHPコード書けてしまうと、システム管理者以外に触らせるのが怖くなるから、わけるべき。
0736nobodyさん2009/09/13(日) 02:02:17ID:???
ﾝじゃ素直にiniファイルにした方が良いのか
0737nobodyさん2009/09/13(日) 06:41:03ID:???
シリアライズフォーマットとして考えると選択肢色々あるけど
設定ファイルならそのFWで標準的なもの使うだけ
0738nobodyさん2009/09/13(日) 09:11:18ID:???
iniじゃ複雑なデータ構造が作りにくい
0739nobodyさん2009/09/13(日) 09:58:40ID:???
そもそもiniにデータ構造突っ込もうとするのが間違ってると思うが。
自前でデータリストのファイル作れば良いじゃん
0740nobodyさん2009/09/13(日) 10:21:25ID:???
自分で、複雑なデータ構造を
パースするようなものを作れと？

そんなもの作るぐらいならYAML使うわｗ
0741nobodyさん2009/09/13(日) 10:27:39ID:???
え、俺なんか難しいこと提案した？
0742nobodyさん2009/09/13(日) 10:44:26ID:???
設定ファイルを難読化する気か
0743nobodyさん2009/09/13(日) 10:48:54ID:???
難しいことじゃなくて、
車輪の再発明（爆笑）を提案した
0744nobodyさん2009/09/13(日) 14:11:52ID:???
<?php
return array
(
設定..
);

で簡単最速
0745nobodyさん2009/09/13(日) 20:19:02ID:???
話が激しくループしてるな。
0746nobodyさん2009/09/14(月) 01:34:52ID:???
YAMLは言語に依存しないところもいいね。
PHPとPerlとかPHPと、Ajaxとか
そういう風に他言語と組み合わさったシステムでも
共通で使える。
0747nobodyさん2009/09/14(月) 10:06:34ID:???
それ、YAMLに限ったことじゃない上に、
iniやXMLのがパーサ多いｗｗ
0748nobodyさん2009/09/14(月) 10:19:23ID:???
たかだか起動時に一度読むだけ、みたいな設定ファイルにパーサ用意すんのもなぁ
ＹＡＭＬはいいとおもうけど、手軽に使えるような土台がまだない感
0749nobodyさん2009/09/14(月) 13:22:47ID:???
YAMLは新しもの好きのミーハーがはやし立ててるだけだろｗ

・パーサが無い(発展途上)
・スペースインデントが面倒、またはエラーの温床になる。
・読みやすいと言われているが、iniやXMLと比べると読み辛い
・XMLに比べて書くのが楽と言われているが、入力補完/バリデーションの整ったXMLの方が現状では楽。

どう考えても、現状では導入するメリット薄い。
0750nobodyさん2009/09/14(月) 13:25:10ID:???
＞・読みやすいと言われているが、iniやXMLと比べると読み辛い

「人間が」読み辛いという意味なら、XMLの方が読みにくいと思うな俺は。
0751nobodyさん2009/09/14(月) 13:35:36ID:???
RubyとかYAMLとか、いろいろ便利だし優れてるっておもうところはたくさんあるけど
導入コストに見合うメリットが足りないんだよねー
0752nobodyさん2009/09/14(月) 14:16:26ID:???
>>750
行数や階層が増えると構造を理解しにくくない？
XMLならビューワによるけど、タグ単位で閉じたり開いたり出来るから行数が増えても無問題なんだけど。
0753nobodyさん2009/09/14(月) 14:45:01ID:???
YAMLの表記って、XMLビューワーの画面そのものだよなｗ
0754nobodyさん2009/09/14(月) 14:51:38ID:???
> ・スペースインデントが面倒、またはエラーの温床になる。
それで思い出したが、XMLはスペースの扱いが大変。

たとえば、
<tag></tag><tag></tag>
と
<tag></tag>
<tag></tag>
は別物。</tag>と<tag>の間に改行があるかないかが違う。

<tag><tag></tag></tag>
と
<tag>
　　　<tag></tag>
</tag>
も別物。改行と先頭のタブ（空白）が違う。

無理やり合わせるために、こういう表現で書く場合もあるくらいだｗ
<tag
　　　　><tag></tag
></tag>

参考
http://www.atmarkit.co.jp/fxml/rensai/xmlwomanabou10/learning-xml10.html
http://www.ibm.com/developerworks/jp/xml/library/x-c14n/
0755nobodyさん2009/09/14(月) 15:45:15ID:???
>>754
お前XML理解してないだろｗ
空白や改行はルートノードの子にあたるテキストノードなんだから別に不思議でも大変でも無いわけだが。


> <tag
>　　　　><tag></tag
> ></tag>

見たことねぇわｗ
パーサ側でホワイトスペース除くなり、該当ノード以外は無視するなりするのが定石じゃね？
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:???
スレタイ読めよ
0856nobodyさん2009/09/19(土) 07:24:20ID:???
設定情報共有フレームワークとしての
ファイルフォーマットとライブラリをだな・・・・
0857nobodyさん2009/09/19(土) 13:20:20ID:???
俺俺フレームワークよりちょっと規模の大きなもの、社内で共有する規模くらいの作ってる人とかいる?
0858nobodyさん2009/09/19(土) 13:55:22ID:???
YAMLなら使ってる
0859nobodyさん2009/09/19(土) 22:52:05ID:???
>>857
たぶんいると思うけど、何が知りたいの？
0860nobodyさん2009/09/20(日) 00:38:15ID:???
ああ、なかまがいた(*'ｗ`)ﾎﾜﾜ
ってやりたいだけ
0861nobodyさん2009/09/20(日) 01:23:09ID:???
俺俺フレームワークって社内で共有するために作る(それも目的の一つ)んじゃないの？
0862nobodyさん2009/09/20(日) 02:01:17ID:???
規模が大きいってそういう意味か
フレームワークより規模が大きいってどういうもの？と思ってしまった
0863nobodyさん2009/09/20(日) 03:16:07ID:???
cakeってwww配下に全部置けるのか
今まで腐ったケーキと馬鹿にしてたけどこの気軽さはいいかも
0864nobodyさん2009/09/20(日) 11:32:36ID:???
なんだよ、Spyc 0.4.2 試したけどバグだらけじゃねーか！

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

おまえ絶対使ってないだろ。20分触っただけでワンサカでてくるんだけど？
・「{ A: 10, B: 20 }」というデータをロードしてvar_exportしたら
　array ( '{ foo' => array ( '10, bar' => '20 }', ), )
　だって。Spycばかじゃねーの？
・日付と時刻が解釈できない。「2009-12-31」がただの文字列。しょぼ。
・マッピングのキーを「"」や「'」でくくるとそれが含まれてしまう。
　たとえば「- "foo": 10」はarray(0=>array('foo'=>10)) になるはずなのに
　array(0=>array("'foo'"=>10)) になる。ふざけてんのか？
・文書区切りの「---」を解釈できない（＝ストリームに未対応）。
・「y」がTRUEになる。たとえば
　- x
　- y
　が array(0=>'x', 1=>TRUE) になる。やめてくれ。
・ブロックスタイルの文字列で最後の改行が消える。たとえば
　- |
　　foo
　だと array(0=>"foo¥n")になるべきところがarray(0=>'foo')。ほんとウンコ。

（つづく！）
0865nobodyさん2009/09/20(日) 11:52:13ID:???
やべー、Spycのバグ、ボロボロ見つかるわ。

・ユニコード書式未サポート。ウンコだから期待してない。

・クォートした文字列で「¥n」が解釈できない。たとえば
　- "aaa¥nbbb"
　が、array(0=>"aaa¥nbbb") のはずが array(0=>'aaa¥¥nbbb') になる。ウンコだから仕方ない。

・ブロックスタイルのインデント幅を指定できない。たとえば
　- text: |2
　　　　　aaa
　　　　bbb
　は aray(0=>array('text'=>"　　aaa¥n　b¥n")) になるはずが、
　array(0=>array('text'=>'|2', 0=>NULL, 1=>NULL)) になった。つくづくウンコ。

・「:」の直後に空白がなくてもキーとみなしてしまう。たとえば
　- &a1
　 name:x
　 age:20
　だと array(0=>array('name'=>'x')) になる。正しくはarray(0=>'name:x')。
　いくらなんでもこれはまずすぎるだろー。とことんウンコ。

・エラーになるべきところでエラーにならない。たとえば
　- aaa: 10
　　bbb: 20
　 ccc: 30　　　# インデントが1つ足りない
　だと3行目でエラーになるはずなのにならない。限りなくウンコ。
0866nobodyさん2009/09/20(日) 12:00:17ID:???
>>826顔真っ赤だな
0867nobodyさん2009/09/20(日) 12:09:39ID:???
ひどいな
0868nobodyさん2009/09/20(日) 12:11:21ID:???
俺は確信した。Spycの開発者って、みのりんのファンなんじゃね？
『（バグを）盛るぜ〜、チョー盛るぜ〜！』
盛り過ぎだろ！

・nullになるべきところで勝手に空配列になってる！
　- foo
　-
　の結果がなんと array(0=>'aaa', 1=>array()) だって！斬新すぎるだろ！

・マージで複数のアンカーを指定できない。つまり「<<: [*anchor1, *anchor2]」という指定方法ができないってことね。

・いらんところで空気読みすぎ。
　- [10, 20, 30, ]]
　はエラーにならないといけないのに、array(0=>arra(10, 20, '30,]')) になるとか。
　そんな空気読まなくていいから！間違った入力にはちゃんとエラーだしてくれていいから！

・spyc-0.4.2.zip ダウンロードしたのに、中に入っている spyc.php のバージョンは @version 0.4.1 だった！
　Spycの開発者は配布するソースのバージョンも管理できてない！
　

もういいわ。疲れた。これ以上調べる気にならん。


>>826
>0.4.2で十分実用レベルになっているだろ。
なってねーよ！おまえがYAMLのさわりの部分しか使ってないだけじゃねーか！

>YAMLは明らかに優れている。
YAMLは優れているかも知れん。しかしSpycはウンコ！にもかかわらず
> 能書きはいいから、今現在どんなバグがあるのかいってみな。
とか自信満々に語るおまえもウンコ！これは絶対！
0869nobodyさん2009/09/20(日) 12:19:26ID:???
>>864
>・「{ A: 10, B: 20 }」というデータをロードしてvar_exportしたら
>　array ( '{ foo' => array ( '10, bar' => '20 }', ), )

間違えた。
・「{ A: 10, B: 20 }」というデータをロードしてvar_exportしたら
　array ( '{ A' => array ( '10, B' => '20 }' ) ) になった。
　（正しくはもちろん array('A'=>10, 'B'=>20) ね。）

Spycはフロースタイルの解釈がまともにできないな。JSONパーサとしては絶対に使えねー。
それ以上に>>826も使えねーやつだろうけどな。

つうかさ、Spycのどこを見てバグがないと思ったんだろうな。よほど初歩的な使い方しかしてないんだろ。
0870nobodyさん2009/09/20(日) 12:23:10ID:???
>>826
>能書きはいいから、今現在どんなバグがあるのかいってみな。

おまえがそんなこというから、調べてやったよ。
あまりにバグが多いから途中で打ち切ったけど、もっと調べりゃまだまだ見つかるはずだぜ。

さあ弁解を聞こうか。人にここまでさせといてトンズラするなよ？
0871nobodyさん2009/09/20(日) 13:46:07ID:???
>858が何事もなくスルーされ、ようやく収束したと思ったのにわざわざ蒸し返す>864がKYウンコすぎる
もう帰れよお前
0872nobodyさん2009/09/20(日) 14:14:59ID:???
痛いとこ突かれちゃったもんね

まぁどっちにしてもYAMLは使うメリットないし、そもそもこの話題はスレ違い
0873nobodyさん2009/09/20(日) 14:47:49ID:???
>>869
はしゃぎ過ぎだろこの長文馬鹿
もうYAMLﾈﾀ勘弁
0874nobodyさん2009/09/20(日) 16:32:37ID:???
いや、カレントバージョンのspycが使えるかどうか
俺も気になってたがテストする気も起きなかったので、
未だに不具合満載ってことが分かっただけでも良かったわ
そういういみではGJ>>864=865=868=869=870
0875nobodyさん2009/09/20(日) 18:20:42ID:???
そうだな。ｽﾚﾁでも有用な情報には違いない。
馬鹿は言い過ぎだ正直ｽﾏﾝかった。
0876nobodyさん2009/09/20(日) 19:22:35ID:???
是非spycスレ立てて続けてくれ。
0877nobodyさん2009/09/20(日) 23:09:34ID:???
ここでいいよｗ
0878nobodyさん2009/09/21(月) 01:01:25ID:???
spycひどいな

俺も損兄つかん込んでる訳じゃないけど、
どうしてもYAMLで行きたきゃ、symfony付属のパーサ使ってた方がまだ安心できる？
0879nobodyさん2009/09/21(月) 02:01:11ID:???
まあ、別にspycがひどくても
それは、YAMLがひどいってことではないからな。

>>865を見て逆に、YAMLの仕様ではこんなこともできるのか！って
驚いた人もいるだろう。
0880nobodyさん2009/09/21(月) 02:28:47ID:???
いえ全然
0881nobodyさん2009/09/21(月) 02:46:25ID:???
設定ファイルはYAMLでもいいかもしんないけど、データフォーマットでXMLの代替に使うならJSONの方がいいと思う。
CouchDBというドキュメント指向データベースだと、JSONでデータを処理できるのでWebアプリとの親和性が高い。

ttp://wota.jp/ac/?date=20090415
>任意のデータ構造を RESTful に扱うことができるドキュメント指向データベースである CouchDB
0882nobodyさん2009/09/21(月) 03:54:06ID:???
>>871
826本人乙。お顔が真っ赤ですよ？いや真っ青か。
そりゃあれだけ自身満々に語ってたもんねー。恥ずかしいったらない。
0883nobodyさん2009/09/21(月) 04:16:56ID:???
もうYAMLはどうでもいいよ。どうせ当分触れる機会なんてない
0884nobodyさん2009/09/21(月) 08:28:10ID:???
YAMLはいいよ。どうでもいいのは826。
0885nobodyさん2009/09/21(月) 10:56:31ID:???
>>882
ネットで顔色がどうしたとかキモイなお前
0886nobodyさん2009/09/21(月) 11:25:05ID:???
>>885
顔色も悪いけど顔がキモイなお前
0887nobodyさん2009/09/21(月) 11:38:08ID:???
「えんがちょえんかちょえんがちょー」
「うるせーお前のかーちゃんでーべーそー」
レベルだな
0888nobodyさん2009/09/21(月) 12:58:52ID:???
PHPってなんでASP.NETと比べて10分の1程度の性能しかでないんですか？
Zendのエンジンがしょぼいんでしょうか？

8 名前：nobodyさん[sage] 投稿日：2009/09/03(木) 16:34:06 ID:???
●ASPとASP.NETのベンチマーク
http://www.atmarkit.co.jp/fwin2k/dnsvrguide/iisperf/iisperf_05.html
●CGI(C++)とASP.NET、ASP、PHPのベンチマーク
http://www.wrensoft.com/zoom/benchmarks.html
●PHPとASP.NETのベンチマーク
http://www.misfitgeek.com/pages/Perf_Tests_PHP_v2_08122009.html
0889nobodyさん2009/09/21(月) 13:07:55ID:???
APCやZendOptimizer入ってないものでテストされても・・・
0890nobodyさん2009/09/21(月) 13:08:35ID:???
あ、APCはあるのか
後はZendOptimezer
0891nobodyさん2009/09/21(月) 13:28:34ID:???
なんで 2003 年のベンチマークか聞きたい
0892nobodyさん2009/09/21(月) 13:40:19ID:???
公式サイトをみると
「Zend Optimizerは、PHPコードの最適化を行ない実行速度を
数％から数十％まで高速化します。」

PHPとASP.NETで10倍以上のスピード差があるならば、Optimizerで
数十パーセント速くなったところで、性能ではASP.NETの
足元にも及ばない気がする。

LAMPを使っているといっていた楽天もショッピングサイトでは
phpの拡張子が見当たらない。
性能面でPHPは使えなかったということなのかな
0893nobodyさん2009/09/21(月) 13:46:06ID:???
拡張子ｗ
0894nobodyさん2009/09/21(月) 14:00:41ID:???
拡張子て
0895nobodyさん2009/09/21(月) 14:04:26ID:???
>>891
>>887の真ん中のベンチマークかなり新しいぞ。
この構成みればかなり最近のってわかるだろう。

Test server specifications:

Intel i7 2.66 GHz
Windows 7 Ultimate (64-bit)
Western Digital 500GB SATA2 GreenPower, 7200 RPM
4 GB of RAM
PHP 5.2.9-1 on Apache 2.2.11
ASP and ASP.NET tested on IIS 7.5.7000.0
CGI (C++) application tested on Apache 2.2.11
JavaScript tested on Internet Explorer 8.0.7000.0
Zoom Search Engine V6 (build 1013), Enterprise Edition
0896nobodyさん2009/09/21(月) 14:09:55ID:???
なに？UNIX系は拡張子などないとかいいうつまらんツッコミ？

PHPが低性能すぎてまったく反論できないから、つまらんところに
ツッコミいれることしかできないんですね。
0897nobodyさん2009/09/21(月) 14:19:05ID:???
「UNIX系は拡張子などない」ｗ
0898nobodyさん2009/09/21(月) 14:26:49ID:???
いいんじゃない。
PHP は ASP より性能低いで。
ASP で開発すればいいんだよwwww
0899nobodyさん2009/09/21(月) 14:33:11ID:???
>>898
wwwつけてるけどあんたがASP, ASP.netをまったく理解して
ないのはわかった。
PHPはASPよりは速い。
ただASP.netには性能面で、完敗。

ASPとASP.netは完全に別物。パフォーマンスもまったく違う。

0900nobodyさん2009/09/21(月) 14:44:13ID:???
拡張子で腹筋が崩壊した
0901nobodyさん2009/09/21(月) 14:48:33ID:???
拡張子わろたｗｗｗ
0902nobodyさん2009/09/21(月) 14:58:42ID:???
拡張子のなにがおもしろいの？
アプリケーションサーバがファイル名から予めデータの
種類がわかれば、最適化した処理ができるんだから、
パフォーマンス向上するでしょ。
IISはそうなってる。
まさかPHPのエンジンはやってないの？
なにがおかしいのかさっぱり。

0903nobodyさん2009/09/21(月) 15:08:26ID:???
予め判ってるんだったら書き換えたって問題ないでしょｗｗｗ
0904nobodyさん2009/09/21(月) 15:20:13ID:???
>>903
なんだ、アウトプット時には書き換えできるとかそんな話？
それだけで笑ってたのか。あほらし。

レンダリング後のファイル名変換ならたしかIISでもできる。
できるけど、変えないほうがパフォーマンス上はいいでしょ。

ファイル名からphpってばれたら恥ずかしいから、.php以外に変えるんですね。
サイト訪れた人が、「PHP（笑）」って腹筋が崩壊しちゃうからなww
0905nobodyさん2009/09/21(月) 15:26:26ID:???
コンパイルして実行する言語と、スクリプト言語の速度を比較しても意味ない。
0906nobodyさん2009/09/21(月) 15:30:29ID:???
>>904
いまどきサイトセキュリティを考えて拡張子を表示しないようにするのは当たり前のことなんだが、
個人サイトしか作らない方はそんなことも知らないのですね、良く判りました。
0907nobodyさん2009/09/21(月) 15:44:04ID:???
>>905
.net frameworkの仕組みまったくわかってないでしょ。
.net系言語、クライアントPCで実行する場合とasp.netでは動きはぜんぜん違う。
asp.netで使用される時のC#.net、VB.netはPHPと同様にスクリプト言語（注）
それでもPHPより10倍以上速い。
>887の2番目のベンチみるとわかるが、C++のCGIに匹敵するスピードを
叩き出してる。

（注）
(最初の実行時にアプリケーションサーバ(IIS)上でプリコンパイルはされるが、
それくらいはPHPでもやってるでしょう？)






0908nobodyさん2009/09/21(月) 16:04:39ID:???
で、PHPフレームワークスレでそれをどう活用したいんだ？
0909nobodyさん2009/09/21(月) 16:06:20ID:???
まーたでたよゲイツ信者
あの界隈はそれだけでひとつに纏まってんだからいちいち他所に沸くなよ
0910nobodyさん2009/09/21(月) 16:25:58ID:???
ド素人どんだけ〜w
0911nobodyさん2009/09/21(月) 16:57:55ID:???
.aspだろうが.phpだろうが.cgiだろうが、隠蔽するのはプロなら普通。
（今どきは素人さんでもやってるが。ちょっと調べればできちゃうし）
デザイン的に言えば、拡張子が出ているのはダサいという風潮がある。
技術的に言えば、URLを実装技術に依存させるのは将来的に困る可能性がある。
加えて、セキュリティ的にも望ましくない。PHPだろうがASPだろうがIISだろうが、可能な限り隠蔽するのが望ましい。
0912nobodyさん2009/09/21(月) 17:15:51ID:???
だいたいフレームワーク使うとスマートURLになるしね
0913nobodyさん2009/09/21(月) 17:39:51ID:???
楽天のサイトってどんな拡張子だったか
思い出してみろｗ
0914nobodyさん2009/09/21(月) 18:12:55ID:???
漢は黙って.exe
0915nobodyさん2009/09/21(月) 21:51:46ID:???
標準のPHP（mod_php）はリクエストの度にソースコードをパースして構文解析、中間コードがコンパイルされて、実行される。毎回そう。
バイナリコードが実行されるASP.NETとは土俵が違う。
とはいえ、.NETアプリケーションがC++のアプリケーションに速度で匹敵するわけない。
もっともこれはウェブサーバやアプリケーションサーバの性能を考慮に入れない場合。
そして、処理内容が言語の速度を問う程に十分複雑な場合の事。
Cでウェブサーバ自体作ってしまえばそれが一番速いし、HELLOWORLD程度のウェブページをCGIで動かすぐらいなら、PHP（mod_php)の方が速い。
0916nobodyさん2009/09/21(月) 21:56:11ID:???
遅いで有名なRoRで作ったtwitterがあれだけのサービスになったんだから
phpで何の問題もないわ
0917nobodyさん2009/09/21(月) 22:14:07ID:???
今でもAPIコケまくってるけどな・・・
0918nobodyさん2009/09/21(月) 22:15:43ID:???
Twitterって今はもうRoRじゃないんでしょ？
0919nobodyさん2009/09/21(月) 22:21:53ID:???
今はcakePHPらしい
0920nobodyさん2009/09/21(月) 22:30:04ID:???
まじ？wwww
俺釣られた？
0921nobodyさん2009/09/21(月) 23:30:15ID:???
結局DBか帯域or接続数辺りがボトルネックになってくるしな。
コードの処理時間がネックになる例ってあまり聞かない。ImageMagickとか使うと話が違うが。
0922nobodyさん2009/09/21(月) 23:38:08ID:???
>915
PHPってプリコンパイルされないの？と驚いてぐぐってみたら
Zend Optimizer使うとプリコンパイルされるような事がかいてあった。
標準構成でプリコンパイルしてくれないってのは遅れてんね
.NET frameworkで動くIronRubyにも性能面で負けちゃうんじゃないの。




0923nobodyさん2009/09/21(月) 23:40:13ID:???
しかし、PHP系のスレは香ばしい奴しかいないのが哀しいな･･･

ASP.net と PHP 比べて云々言う奴は、
WEBサーバ含めてCでフルスクラッチすればいいんじゃないかね？ｗ

PHPの動作速度で実用上問題になるサイトはほとんど無い。
大抵はDBや通信部分のボトルネックが大きい。
0924nobodyさん2009/09/21(月) 23:57:44ID:???
なんで ASP.NET が普及していないのかは考えないんだね
0925nobodyさん2009/09/22(火) 00:29:26ID:???
ASP.NETは普及してると言えば普及してる。PHPが選ばれるケースとは要求条件が違うだけ。それはJava EEとかもそう。
0926nobodyさん2009/09/22(火) 00:39:30ID:???
だから、普通に考えたら、確かにAPCとかのキャッシュを標準にすると思う。mod_perlとかmod_railsとか、Javaのコンテナとか、それが当たり前だし。
が、PHPの場合、極力簡単にウェブアプリを作る事だから。開発者にキャッシュを使いこなす事を求めるより、デプロイの単純さを選択してるんだろう。
0927nobodyさん2009/09/22(火) 02:17:18ID:???
facebookなんてトップページhome.phpだぜ

2億5千万が利用してるサービスがPHPで拡張子出してる。
URIは変わらない事が大事なのであって余計な情報を見せないようにとか結構どうでもいい話。
0928nobodyさん2009/09/22(火) 02:20:00ID:???
ホントこのスレって、スレ違いの話題で埋め尽くされてるよな。
スレ違いの話題を延々してる奴、いい加減にしとけよ。
0929nobodyさん2009/09/22(火) 06:43:00ID:???
古いどうしようもないサイトはそうだけど
そんなサイトいじってるだけの仕事なんて日に日に減ってって後ないじゃん
新しいの立ち上げるときもそんなURIつかってたら客に笑われるわｗ

だいたい昨今のフレームワークならこのあたりの機能はついてるし、別段難しいもんでもないよな
0930nobodyさん2009/09/22(火) 09:46:31ID:???
>>925
ASP.NET で有名なサイト 3 つだけでいいから教えて。
MS 以外で。
0931nobodyさん2009/09/22(火) 09:54:57ID:???
イントラ用途っていう話なんじゃないのかな？
0932nobodyさん2009/09/22(火) 10:09:14ID:???
>>930
俺が知ってるのはソフマップぐらいだなあ
0933nobodyさん2009/09/22(火) 10:38:46ID:???
>>925
IIS(ASP.net)はWEBサーバのシェア20〜25%。
商用製品のWEBサーバとしてはトップ。
当然ながらイントラネット内の業務用ならもっとシェア高い。

大規模サイトなんていくらでもあるよ。特に欧米。非MS系だと
知る限りで一番トラフィック大きそうなところは、オークションのeBayかな
MS系だけでもHotmailやらLive Search(Bing)やらは相当なトラフィックかと。
0934nobodyさん2009/09/22(火) 10:54:15ID:???
eBay も MS 系だからなぁ。
大規模サイトでいくらでもあるなら 3 つ挙げてよ。
0935nobodyさん2009/09/22(火) 11:08:32ID:???
お前ら
他所でやれ
0936nobodyさん2009/09/22(火) 11:14:51ID:???
まったくだ。
0937nobodyさん2009/09/22(火) 11:19:14ID:???
絵BayはMS系の会社ではないだろ。

大規模サイトでたくさんあるって言葉が信じられないなら、
WEBサーバのシェアと、ASP.NETのベンチマーク結果いろいろ調べれば。
シェア20%以上あって、ベンチマークも最速なんだから、
多くの導入事例があることくらい容易に想像できそうなもんだけど。
0938nobodyさん2009/09/22(火) 11:30:19ID:???
数字はお金のチカラですね、わかります。
0939nobodyさん2009/09/22(火) 11:55:57ID:???
捏造可能なベンチマークやシェアの数字に必死にしがみついて生きていけ。Ｂ層さん？
0940nobodyさん2009/09/22(火) 12:28:35ID:???
捏造したという話そのものが

捏造

0941nobodyさん2009/09/22(火) 12:40:01ID:???
http://channel9.msdn.com/posts/philpenn/FASTCGI/
0942nobodyさん2009/09/22(火) 13:02:40ID:???
結論
オラはアパッチじゃなきゃいやずら
ウララー
いなりずし1000個食うタイ
0943nobodyさん2009/09/22(火) 13:18:26ID:???
ヨドバシドットコムって、ポイントがリアル店舗と共通じゃん。これは凄い。
リアル店舗のPOSとウェブが連動しなければならない。そうなると業務アプリに対応出来るJavaかMS系を採用することになる。
PHPはビジネスロジックが簡単なウェブサイトを作るのに向いてる。
何てことない掲示板サイトだってトップクラスのアクセスを集めることもある。そういうのにPHPは向いてる。
アクセスをさばくのはインフラの問題であって、言語が影響する事は少ないから。すると、PHPは無料だし、PHP開発者も単価が安いので、PHPが選ばれる。
0944nobodyさん2009/09/22(火) 13:37:47ID:???
> ヨドバシドットコムって、ポイントがリアル店舗と共通じゃん。これは凄い。

実はウェブの注文を店員がレジでポイント加算しているだけ。

ソース俺

ぜんぜん、すごくないよーｗ
0945nobodyさん2009/09/22(火) 13:42:11ID:???
マジレスすると、POSといってもレジは関係なく、
POSのサーバー（データベースにRDBMSを使用しているだろう）
にアクセスすれば良いだけだからPHPからポイント共通処理は行える。

言うまでも無いが、MySQL、PostgreSQLだけでなく、商用のOracleやMS SQL Serverにも
PHPからアクセスできる。
0946nobodyさん2009/09/22(火) 13:49:43ID:???
>>944
マジか
それはそれで凄いな
0947nobodyさん2009/09/22(火) 14:04:09ID:???
>>943
みたいな素人は本当に恥ずかしい。
JavaかMS系にしなくてはならない理由を明確に書いてみろよｗ


店舗POSとの連携システムをいくつか作ってきているが、
大抵はRDBMS経由での連携になるので開発言語は特に関係無い。
0948nobodyさん2009/09/22(火) 14:20:10ID:???
>>926
まあそれでも需要はあるわけでPHP6からAPCが標準だそうな
0949nobodyさん2009/09/22(火) 14:21:26ID:???
>>929
クエリー出してたら恥ずかしいとかも思ってる？
笑われてるのは誰だか分からんな
0950nobodyさん2009/09/22(火) 14:24:23ID:???
>>921
確かにwebはDBよりスケールアウトしやすい。
だが5台必要だったwebサーバーが3台で済めばそれはそれで幸せじゃないか。
なのでスクリプト速度が重要でないという話にはならない。
0951nobodyさん2009/09/22(火) 14:43:48ID:???
>950
開発速度が同じならな
あと人間の確保のしやすさ
0952nobodyさん2009/09/22(火) 16:27:34ID:???
>951
PHPの方がJavaやC#より開発効率がよいとでも？
エンジニアが確保しやすいとでも？
0953nobodyさん2009/09/22(火) 16:29:58ID:???
小規模なサイトならスクリプト系の言語の方が工数は少なくなるが、
ある程度の規模以上であれば、あまり言語は関係なくなるような気がする。
0954nobodyさん2009/09/22(火) 16:31:59ID:???
Javaは分からんでもないが、C#でまともにプログラムできる人間に会ったことが無いわ
0955nobodyさん2009/09/22(火) 17:58:33ID:???
>952
・（小規模であれば）開発効率が良い
・（単価を考慮すれば）人間が確保しやすい
開発速度にしたって、環境構築まで勘定に入れれば速かろうよ
いや、俺は自社サービス系だから、BtoB系の事情は良く分からんが
0956nobodyさん2009/09/22(火) 18:08:03ID:???
適材適所。システムの規模というより、
多くのレンタルサーバーで動かそうとしたら
PHPしか選択肢が無いのが現実。
0957nobodyさん2009/09/22(火) 18:12:31ID:???
うちは、Web系の仕事はPHPも.NETもJavaもやっているSIなんだけど。
PHPの最大のメリットは、開発効率や人間の単価なんかではなくて、
小規模ならレンタル鯖でも動かせる、大規模でもライセンス料がかからない、
Apacheが動く鯖さえ用意すれば済むと言うところだな。
ちなみに、BtoBではJavaが必要っていうのは完全に思い込みだと思う。
あと、イントラ用途での.NET(Web Forms)の生産性は、用途によっては
他の追随を許さないレベル。
0958nobodyさん2009/09/22(火) 19:15:51ID:???
うちもPHP/.NET/Java何でもやるけど、
PHPのメリットはサーバ代などが安いから利益率を高められること。。
0959nobodyさん2009/09/22(火) 19:54:11ID:???
.NETはライセンス無視しまくってやっと利益が出る程度だかんなぁ
あー、はやくこんな中華系の糞会社やめてぇって毎日思いながら
割れものつかって開発してるぜ

それはさておき、フレームワークといえば、
仕事でってのはまだなさそうだけど個人でYiiつかってみてるひとっている？
0960nobodyさん2009/09/22(火) 20:19:20ID:???
開発費の回収は後々のサービス費1年ぐらいでやっと回収できるっつーかそういう計算なんだもんな
最初の費用だけで回収できるのは結局使いまわしできる案件だけ、そしてそんな案件10もねぇよ・・・
0961nobodyさん2009/09/22(火) 21:42:00ID:???
おまえらエンジニアだろ。コストなんてどーでもいいじゃん。
言語としてPHPよりC#の方がおもしろいぜ。
0962nobodyさん2009/09/22(火) 21:46:02ID:???
ぉぃｗ逆だろｗ
0963nobodyさん2009/09/22(火) 21:56:30ID:???
うむ、逆だなｗ
まあ、俺も正しいことと楽しいことが違う人間だし、PHPよりもC#の方が好きだけど。
0964nobodyさん2009/09/22(火) 22:07:56ID:???
C#は後発だけあってよく出来てる。LINQとかな。PHPは簡単に覚えられるってこと以外、まるでメリットないと思う。仕事だから使ってるけど。
0965nobodyさん2009/09/22(火) 22:10:56ID:???
C#はGC使わなくするオプション付いた？
以前それで動かなかったから捨ててたんだが
0966nobodyさん2009/09/22(火) 22:21:34ID:???
>>965
オマエは.NETを使わなくてもいいよ。
0967nobodyさん2009/09/22(火) 22:29:06ID:???
PHPの方がおもしろいとか言ってる奴なんなのｗｗｗ
0968nobodyさん2009/09/22(火) 22:37:01ID:???
そんなこと言ってるやついるのか？ｗ
0969nobodyさん2009/09/22(火) 22:55:42ID:???
つーか、再三スレ違いと指摘されてもグダグダくだらん話題で
引っ張る奴こそなんなの？　だな。
0970nobodyさん2009/09/22(火) 23:19:37ID:???
たまにフレームワークの話がでてきても〜使ってる人いる?のレス付かずでお終い
0971nobodyさん2009/09/22(火) 23:28:31ID:???
で、PHPのフレームワークで決定版って何だろ。

RORみたいな定番ってないのかな。Zendも、現場
じゃあまり使われてないみたいだし。

または、Zendベースのさらなるフレームワークとか、
CMSとかないのかな。
0972nobodyさん2009/09/23(水) 00:29:17ID:???
>>970
yiiについてはちらほらと話題に出てきては（使ってる人間少なすぎて）レスつかずだね
俺も気になってはいるが、Cakeから離れられない
RoRみたいな決定版がないのも、Webアプリ使用前提で発展してきたPHPならではともいえる。
0973nobodyさん2009/09/23(水) 02:21:44ID:???
恐らくPHPのフレームワークに決定版など出てこない

分散的にそれぞれが発展するものと思われ、またそれでいいのではと
0974nobodyさん2009/09/23(水) 02:57:24ID:???
ところで、俺俺フレームワークもどきの話をしないか？
0975nobodyさん2009/09/23(水) 03:03:50ID:???
お断りです
0976nobodyさん2009/09/23(水) 09:12:44ID:???
Ruby界隈も最近はRoRオンリーってわけじゃないけどな。
Cake同様の「全部入り」に不満を抱いた連中が軽量フレームワークに動いてる。
PHPにもその流れはある程度影響してるが。
0977nobodyさん2009/09/23(水) 09:37:47ID:???
シナトラのこと？
0978nobodyさん2009/09/23(水) 09:52:47ID:???
Zendはモデルへのアクセス方法を早急に提供しなさい
0979nobodyさん2009/09/23(水) 10:18:06ID:???
>>974
設定ファイルのフォーマット以外を頼む
0980nobodyさん2009/09/23(水) 10:25:40ID:???
Rubyはこれ以上伸びそうにもないな。2年くらい前のRailsブームがピークだったな。楽天が松本呼んだりしてたが、あれまだやってるんだろうか。
0981nobodyさん2009/09/23(水) 15:11:25ID:???
俺俺フレームワークって、各種オープンソースなライブラリを使いやすい形にラップした物が多いから公開しにくいってのもあるよねぇ･･･

俺が作ってるのは
シンプル、軽量、1ディレクトリアップロードするだけで動作、コードの自動生成は無い代わりにデバッグ機能が充実
で、データベースやHTTPクライアント等の実装に手間がかかる部分はZendFWを組み込んでる。

フレームワークというより、
個々の手法で最初に行っている初期化処理を纏めたようなクラス群か。
0982nobodyさん2009/09/23(水) 16:26:48ID:???
PHP Rules ってのはどうなんでしょ
0983nobodyさん2009/09/23(水) 18:32:43ID:???
>>982
PHP最高！
0984nobodyさん2009/09/23(水) 19:35:37ID:???
>>981
すぐに公開すべき
0985nobodyさん2009/09/23(水) 20:54:32ID:???
どんな言語でもデバッグするためのライブラリを
標準で用意してほしい。

print_rみたいに、クラス・構造体の内容を
見やすく表示したり、

PHPの話じゃないけど、定数の値から、定数名を表示したり。
レス数が950を超えています。1000を超えると書き込みができなくなります。