【PHP】フレームワークについて語るスレ13【総合】
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/
●国外産●
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/
|
|
|
●過去スレ一覧
【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/
【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/
●関連しそうなスレ
【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/
【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/
980レスを超えてしまったため、新スレ立ておよび誘導前に落ちたようです
980レス付近になったら、次スレの準備をお願いいたしますで候
では引き続きフレームワークとは関係ない話題はほどほどにしつつ適当に語りましょう
980レス付近になったら、次スレの準備をお願いいたしますで候
では引き続きフレームワークとは関係ない話題はほどほどにしつつ適当に語りましょう
いいかげんテンプレにピースFWも入れてあげて
6 ：nobodyさん：2009/03/24(火) 15:21:25 ID:vm768fgW
おせえよ
全然使えない感じだったzfも、いつの間にか機能充実してるね
form関係はよさげ
form関係はよさげ
zf重いよ・・・
なんで重いん？
http://www.ibm.com/developerworks/jp/opensource/library/os-php-5.3new5/?ca=drs-jp
5.3でeregが非推奨になってるけど
pregだとマルチバイト文字列を簡単に扱えないじゃん
なめてんの？
5.3でeregが非推奨になってるけど
pregだとマルチバイト文字列を簡単に扱えないじゃん
なめてんの？
と思ったらutf-8ならpregでも扱えるのか
にゃは
にゃは
数年前からずっと続いているutf-8化への流れにあくまで逆らう人間は
それなりの苦労をすればいい、ってことだろう
それなりの苦労をすればいい、ってことだろう
14 ：nobodyさん：2009/03/28(土) 01:24:33 ID:zO5Id0L9
UTF-8の文字化けは、とりあえず「波ダッシュ問題」だけ気を付ければOKですか？
他にメジャーな文字化け現象はあるんでしょうか？
波ダッシュ問題 の検索結果 約 69,200 件
他にメジャーな文字化け現象はあるんでしょうか？
波ダッシュ問題 の検索結果 約 69,200 件
UTF-8 文字化け の検索結果 約 583,000 件
>>14
文字化けの原因を大別すると
１．文字セット間での変換時の変換テーブルの相互互換性の問題
２．データを処理する際のエンコーディングの取り違え
だと思うんだ。もちろん上記は複合する。
んで、波ダッシュ問題っての？その原因は１の方で、これは文字コードの変換さえしなければ起こらない。
例えばPHPはUTF-8で、DBがEUC-JPとかいうわけのわからん構成でシステム組んだりするとそんなことが起こるよ、と。
もうちょっとやらしいところでは、例えばJavaで動いているEclipseでeuc-jpのコードを書いたりすると、同じ原因で波ダッシュが化けたりする。
だから、ぶっちゃけ文字コードの変換を極力避けるシステムを作ればいい。
その為にはUTF-8が一番有効ですよっていうのが脳みそシンプルで簡単なやり方。
メール送信時だけ、今のところISO-2022-JPにしなきゃいけないみたいな現状はあるけど、そのほかはほぼUTF-8でいけるはず。
さて、勉強の為にツッコミを希望しますｗ
文字化けの原因を大別すると
１．文字セット間での変換時の変換テーブルの相互互換性の問題
２．データを処理する際のエンコーディングの取り違え
だと思うんだ。もちろん上記は複合する。
んで、波ダッシュ問題っての？その原因は１の方で、これは文字コードの変換さえしなければ起こらない。
例えばPHPはUTF-8で、DBがEUC-JPとかいうわけのわからん構成でシステム組んだりするとそんなことが起こるよ、と。
もうちょっとやらしいところでは、例えばJavaで動いているEclipseでeuc-jpのコードを書いたりすると、同じ原因で波ダッシュが化けたりする。
だから、ぶっちゃけ文字コードの変換を極力避けるシステムを作ればいい。
その為にはUTF-8が一番有効ですよっていうのが脳みそシンプルで簡単なやり方。
メール送信時だけ、今のところISO-2022-JPにしなきゃいけないみたいな現状はあるけど、そのほかはほぼUTF-8でいけるはず。
さて、勉強の為にツッコミを希望しますｗ
cakephp とシンフォニーで迷っています
名前からするとcakephpが一番良く思えるのですが
名前からするとcakephpが一番良く思えるのですが
そんな人にはzf
ちいたん使ってる人いる？
ちいたんとかいうの使うくらいなら自分でシンプルなFW書いた方がよくね？
ZF使えばよくね？
ZFは激重だという噂が・・
いや全然？
ＣＩとどっちが早い？
何を比べるの？
Hello World？
ぶっちゃけ、ページ表示で多少引っかかるくらいの重さなら許容範囲内って仕事が9割5分。
FWの差異以前に、DBの組み方であるとかサーバや回線そのものの差が、サイトの重さの差に
占めるウェイトの8割以上、とかやけくそ気味に考えることも多い。
Hello World？
ぶっちゃけ、ページ表示で多少引っかかるくらいの重さなら許容範囲内って仕事が9割5分。
FWの差異以前に、DBの組み方であるとかサーバや回線そのものの差が、サイトの重さの差に
占めるウェイトの8割以上、とかやけくそ気味に考えることも多い。
仮に俺俺フレームワーク作るとしたら、
みんな何のフレームワークをお手本に作る？
みんな何のフレームワークをお手本に作る？
まぜこぜかな
俺俺フレームワーク作り始めました。
よろしくお願いします。
よろしくお願いします。
cakephpはphp4なのがちょっと
何か色々ツッコミたくなるレスだなw
>>28
コーディングスタイルはZend
コーディングスタイルはZend
いまからPHPフレームワークさわるんならYiiでイーんじゃね？
新しい分活発だろうし
新しい分活発だろうし
自分の場合、使い方を覚えるのが一番早かったのがCI。
CIは解説本を１冊読んでチュートリアルのサンプルを作ったら、１週間程度で使い方が理解できた。
紆余曲折、結局WEBアプリの作成って、DBのラッパー作りだと納得した。
スカッフォルディングは使ってないけど、今ではFW（CI）のおかげでだいぶ生産性が上がり、楽ができるようになった。
とにかく何でもいいから１つFWをものにして、それを基準にして他と比較して、他が良ければ鞍替えすればいいと思う。
CIはシンプルなので、足りない機能があればZFから借用できる。
＝解説本にZFライブラリの利用方法が解説されていた。
CIの欠点は、CIがアメリカ製なので日本の携帯端末用ページを作るには不足が多いかもしれないということ？
CakePHPとSymfonyも一応解説本に目を通したが、覚えることが多そうだったので使わなかった。
CIよりも自分の開発規模・用途に適した、よさげなFWが登場したら、鞍替えすると思う。
CIは解説本を１冊読んでチュートリアルのサンプルを作ったら、１週間程度で使い方が理解できた。
紆余曲折、結局WEBアプリの作成って、DBのラッパー作りだと納得した。
スカッフォルディングは使ってないけど、今ではFW（CI）のおかげでだいぶ生産性が上がり、楽ができるようになった。
とにかく何でもいいから１つFWをものにして、それを基準にして他と比較して、他が良ければ鞍替えすればいいと思う。
CIはシンプルなので、足りない機能があればZFから借用できる。
＝解説本にZFライブラリの利用方法が解説されていた。
CIの欠点は、CIがアメリカ製なので日本の携帯端末用ページを作るには不足が多いかもしれないということ？
CakePHPとSymfonyも一応解説本に目を通したが、覚えることが多そうだったので使わなかった。
CIよりも自分の開発規模・用途に適した、よさげなFWが登場したら、鞍替えすると思う。
36 ：nobodyさん：2009/04/16(木) 19:38:44 ID:PXJUiMOk
そこだけPEAR?
携帯のUA判定ぐらいなら、自前で書いたほうが早い気がするけど。
>>39
早いだけでどうせ穴だらけなんだろｗ
早いだけでどうせ穴だらけなんだろｗ
>>40
＞その程度のノウハウを独占できる時代は終わってるんだぜｗ
まさしくその程度のノウハウだし、きっちり携帯切り分けるなら結局IPみたりするんだし、
やっぱり自前でやってもそんなに問題のあるコードが出てくるとはおもわなんだが。
>>41
ん〜、Net_UserAgent_Mobileに穴がない保証が見つからないし、あそこまでUAから
情報が必要になることもなさそうだしなぁ。
最近は、よさげな野良ライブラリ見つけたのでそれを参考に作ってみたりしたけど。
あと、インプレスが携帯電話の情報を無償提供とかやってるみたいだし、
結局PEARのライブラリの使いどころって、見えないなぁ。
＞その程度のノウハウを独占できる時代は終わってるんだぜｗ
まさしくその程度のノウハウだし、きっちり携帯切り分けるなら結局IPみたりするんだし、
やっぱり自前でやってもそんなに問題のあるコードが出てくるとはおもわなんだが。
>>41
ん〜、Net_UserAgent_Mobileに穴がない保証が見つからないし、あそこまでUAから
情報が必要になることもなさそうだしなぁ。
最近は、よさげな野良ライブラリ見つけたのでそれを参考に作ってみたりしたけど。
あと、インプレスが携帯電話の情報を無償提供とかやってるみたいだし、
結局PEARのライブラリの使いどころって、見えないなぁ。
PEARで一括りにする時点で、何かが違うと感じた。
それとはまた矛盾するかも知れない話ではあるが、少なくとも情報の集積という点で、
「よさげな野良ライブラリ」よりPEARに荷担したくなる自分もいる。
結局、あれだ。「自前で書いたほうが〜〜」に反発しただけなんだと思うわけだ。
>>42が気分を損ねて無いなら幸い。
それとはまた矛盾するかも知れない話ではあるが、少なくとも情報の集積という点で、
「よさげな野良ライブラリ」よりPEARに荷担したくなる自分もいる。
結局、あれだ。「自前で書いたほうが〜〜」に反発しただけなんだと思うわけだ。
>>42が気分を損ねて無いなら幸い。
自己レス
> PEARで一括りにする時点で、何かが違うと感じた。
これ先にやったの俺だな。
ごめん。読み流してやって下さい
> PEARで一括りにする時点で、何かが違うと感じた。
これ先にやったの俺だな。
ごめん。読み流してやって下さい
>>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が表示できる出来ないの情報を付加したものを作りました。
特に気を損ねたりはしてないです。
「自前で書いたほうが〜〜」という件については、
まぁ、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が表示できる出来ないの情報を付加したものを作りました。
Request と Response という2つのクラスを作って、さらにこれをまとめるクラスを作りたい。
だけどいいクラス名が思いつかない。なにかいい名前プリーズ。
/// つくりたいクラス
class Http {
var $request;
var $response;
function Http() {
$this->request = new Request();
$this->response = new Response();
}
}
だけどいいクラス名が思いつかない。なにかいい名前プリーズ。
/// つくりたいクラス
class Http {
var $request;
var $response;
function Http() {
$this->request = new Request();
$this->response = new Response();
}
}
活発さなら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
ほかは無いも同じだな。
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
ほかは無いも同じだな。
>>46
分ける必要なくね？
分ける必要なくね？
違った逆だｗ
まとめる必要なくね？
まとめる必要なくね？
51 ：nobodyさん：2009/04/21(火) 05:05:52 ID:TMA0XNZY
>>51
こいつ来るだろうなぁと思ってたらやっぱり来たwww
こいつ来るだろうなぁと思ってたらやっぱり来たwww
しかしまさかMySQLがオラクルのものになる日が来るとはね・・
Javaも脂肪したからむしろPHP復活ｗｗｗ
55 ：nobodyさん：2009/04/21(火) 22:20:27 ID:8G0hNlN6
空気読まず貼りますね
http://www.cbook24.com/shop/ProductDetail.aspx?sku=9784798022574&CD=F1000049&WKCD=F1000037
http://www.cbook24.com/shop/ProductDetail.aspx?sku=9784798022574&CD=F1000049&WKCD=F1000037
Zendも買っちゃえよｗ
57 ：nobodyさん：2009/04/22(水) 23:50:12 ID:6FnKU0By
PHPにフレームワーク要るか？少なくとも自家製テンプレートは本当に邪魔なだけだろ。
自家製テンプレートってなに？
Yiiイイヨー
Yii よくねえよwwwwwwwwwwwww
Yiiって速いらしいじゃん、ほんと？
>>57
同意。
・PHPは簡単だから、デザイナーやHTMLコーダーでもすぐに理解できる（分業が目的でもテンプレートシステムは不要）
・生PHPの方が、テンプレートの独自記法よりも多機能で便利
条件分岐や繰り返しは、生PHPで書いても可読性は確保できます
http://codeigniter.jp/user_guide_ja/general/alternative_php.html
だから、MVCのVも、Smarty等のテンプレートシステムはなくてもOK
同意。
・PHPは簡単だから、デザイナーやHTMLコーダーでもすぐに理解できる（分業が目的でもテンプレートシステムは不要）
・生PHPの方が、テンプレートの独自記法よりも多機能で便利
条件分岐や繰り返しは、生PHPで書いても可読性は確保できます
http://codeigniter.jp/user_guide_ja/general/alternative_php.html
だから、MVCのVも、Smarty等のテンプレートシステムはなくてもOK
キャッシングは？
acom
>>62
テンプレートエンジンの思想は、PHP構文を置き換える目的では無いよ。
・デザイナに与える権限を最小限にする(PHPを直に触らせない)
・結果的にコード記述方法が統一される
・PHP以外の言語からも再利用出来る
・キャッシングや独自タグなどの拡張が楽
・可読性が生PHPと比べて高い
等メリットはあるし、ケースバイケースだね。
テンプレートエンジンの思想は、PHP構文を置き換える目的では無いよ。
・デザイナに与える権限を最小限にする(PHPを直に触らせない)
・結果的にコード記述方法が統一される
・PHP以外の言語からも再利用出来る
・キャッシングや独自タグなどの拡張が楽
・可読性が生PHPと比べて高い
等メリットはあるし、ケースバイケースだね。
記述内容（≒作業中の意識）をレイアウト層に特化するといった意味でもテンプレートエンジンは有用。
ただHTMLもレイアウトを記述するためのものでは無いので、PHPやHTMLに毛が生えたような構文である必要はなく、
独自のテンプレート記述言語もいいかもしれない。
生産性の観点から言うとひとつのテンプレートからPC用HTML、携帯用HTML、Ajax用データetc.を吐けたりすると嬉しい。
ただHTMLもレイアウトを記述するためのものでは無いので、PHPやHTMLに毛が生えたような構文である必要はなく、
独自のテンプレート記述言語もいいかもしれない。
生産性の観点から言うとひとつのテンプレートからPC用HTML、携帯用HTML、Ajax用データetc.を吐けたりすると嬉しい。
WEBサイトのシステムは、MVCに分割すれば、それだけでも保守性の確保は十分だと思う。
VのところでSmarty等のテンプレートエンジンを使うか、使わないか？
HTMLの中にPHPのコードを埋め込めるから、生PHPそれ自体が一つのテンプレートエンジンとして使える。
生PHPよりも高機能なPHP製テンプレートエンジンってないから、生PHPは便利ですよ。
以前はSmarty使っていたけど、今は生PHPに戻りました＾＾
テンプレートエンジンを使う人には、それなりに理由があるだろうから、別に否定はしないけど。
VのところでSmarty等のテンプレートエンジンを使うか、使わないか？
HTMLの中にPHPのコードを埋め込めるから、生PHPそれ自体が一つのテンプレートエンジンとして使える。
生PHPよりも高機能なPHP製テンプレートエンジンってないから、生PHPは便利ですよ。
以前はSmarty使っていたけど、今は生PHPに戻りました＾＾
テンプレートエンジンを使う人には、それなりに理由があるだろうから、別に否定はしないけど。
> 生PHPよりも高機能なPHP製テンプレートエンジンってないから、生PHPは便利ですよ。
lol
lol
これはひどい
生PHPに自動escapeがあれば検討に値するんだがな
>>71
そのくらい作れよ
そのくらい作れよ
viewにオブジェクトなんか持って行くようなつくりだと、FW側でのエスケープは難しい、というか煩雑だろうな。
テンプレートの記述でちょろっと書いたらescape（または非escape）ってのが今のところベターな気がする。
生のPHPで E() とかグローバル関数を作って使ってもいいんだろうが、一気にきちゃなくなりそうだ。
テンプレートの記述でちょろっと書いたらescape（または非escape）ってのが今のところベターな気がする。
生のPHPで E() とかグローバル関数を作って使ってもいいんだろうが、一気にきちゃなくなりそうだ。
>>71
例えば、
<? ?> #=> <?php ?>
<?= ?> #=> <?php echo ?>
に加えて、
<?== ?> #=> <?php echo エスケープ処理(); ?> （処理内容はPHP_INI_ALLで設定可能）
みたいなタグを追加する、とか？
こんな感じで実装されれば、ショートタグ全盛時代がくるだろうな。
例えば、
<? ?> #=> <?php ?>
<?= ?> #=> <?php echo ?>
に加えて、
<?== ?> #=> <?php echo エスケープ処理(); ?> （処理内容はPHP_INI_ALLで設定可能）
みたいなタグを追加する、とか？
こんな感じで実装されれば、ショートタグ全盛時代がくるだろうな。
そこまでして数文字節約できて本当に嬉しいの
>>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 ?>"/>
うん。下の方が嬉しいな。
「文字数を節約する」のは特にメリットはないけど、
読みやすくする、その場所で大事でないことはあんまり目に入らないようにするっていうのは
とてもメリットがある。
<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 ?>"/>
うん。下の方が嬉しいな。
「文字数を節約する」のは特にメリットはないけど、
読みやすくする、その場所で大事でないことはあんまり目に入らないようにするっていうのは
とてもメリットがある。
テンプレートエンジン使えよ
>>75
どうせphp本体に手を入れるのなら、「出力は全て自動エスケープされる」モードを作った方がよくね。
俺は今、テンプレートに変数を割り当てた時点(FW側)で全てエスケープされるようにして、
変数にHTMLタグを割り当てた場合、テンプレート側でデコードするようにしている。
但し、>>74の言うようにオブジェクトは除いて別扱いせざるを得ない。
<?php echo や <?= なら自動エスケープ。<?== ならそのままってなほうがいい。
どうせphp本体に手を入れるのなら、「出力は全て自動エスケープされる」モードを作った方がよくね。
俺は今、テンプレートに変数を割り当てた時点(FW側)で全てエスケープされるようにして、
変数にHTMLタグを割り当てた場合、テンプレート側でデコードするようにしている。
但し、>>74の言うようにオブジェクトは除いて別扱いせざるを得ない。
<?php echo や <?= なら自動エスケープ。<?== ならそのままってなほうがいい。
>>79
理屈はわかるけど、あくまでも、特殊処理をする方を特殊な書き方にした方がいいと思うな。
magic_quotesの悪い前例もあることだし。
それにそうしないと、例えばファイルに書き出すときにはモードをオフに、とかしなきゃいけなくなる。
まあおれの場合は実装の絡まない妄想だが。
理屈はわかるけど、あくまでも、特殊処理をする方を特殊な書き方にした方がいいと思うな。
magic_quotesの悪い前例もあることだし。
それにそうしないと、例えばファイルに書き出すときにはモードをオフに、とかしなきゃいけなくなる。
まあおれの場合は実装の絡まない妄想だが。
htmlのレンダリングにおいてはescapeしないほうが特殊な処理だし、
安全性を考えたらdefaultでescapeのほうがいいと思うけどね。
安全性を考えたらdefaultでescapeのほうがいいと思うけどね。
>>80
ちょっと書き方が悪かった。
あくまでFWのview出力において全て自動エスケープ。
たとえば $view->display()としたときにdisplayメソッド内で自動エスケープをONにして
テンプレートスクリプト(生PHP)を処理していく感じ。
ちょっと書き方が悪かった。
あくまでFWのview出力において全て自動エスケープ。
たとえば $view->display()としたときにdisplayメソッド内で自動エスケープをONにして
テンプレートスクリプト(生PHP)を処理していく感じ。
defaultでescapeとかまともに考えたらありえない。
magic_quotes以上のゆとり思考だろ・・・
<?== ?> タグ程度なら、自前で実装出来そうだし、
用意された機能で実装すりゃいいんじゃねーの？
それをテンプレートエンジンと呼ぶかどうかは別にして
magic_quotes以上のゆとり思考だろ・・・
<?== ?> タグ程度なら、自前で実装出来そうだし、
用意された機能で実装すりゃいいんじゃねーの？
それをテンプレートエンジンと呼ぶかどうかは別にして
何か問題でも?
>>83
前段二行は、まあPHPとはそういう言語（？）だと。
他にもmb_stringの自動変換とかsafe_modeとか、もろもろの余計なお世話で
成り立ってるんだし、他の機能と比べればHTMLエスケープの標準オプション化くらい
なんてことはない。
ただ、エスケープの為だけにタグを"スクリプトでの"実装はあり得ないなｗ
後半はそういう意図に読めるが、それだけのテンプレートエンジンなんて筋が悪すぎる。
PHP拡張としてパーサレベルで実装してあれば便利かな、ってものだと思う。
前段二行は、まあPHPとはそういう言語（？）だと。
他にもmb_stringの自動変換とかsafe_modeとか、もろもろの余計なお世話で
成り立ってるんだし、他の機能と比べればHTMLエスケープの標準オプション化くらい
なんてことはない。
ただ、エスケープの為だけにタグを"スクリプトでの"実装はあり得ないなｗ
後半はそういう意図に読めるが、それだけのテンプレートエンジンなんて筋が悪すぎる。
PHP拡張としてパーサレベルで実装してあれば便利かな、ってものだと思う。
だからsmarty使えばいいじゃん
{$var}で解決よ
{$var}で解決よ
じゃSmarty使わない理由をまとめてくれ
>>89
すごく消極的だが、前提ライブラリは少なければ少ない方がいい、とか。
Smarty以外にもテンプレートエンジンはあるし、どれも標準にはなり得ない。
最近のFWでもテンプレートエンジンを必須の前提にしていないものが大半だが、
その理由と同じってのでどうだろう。
俺は使えればSmarty使う派だから想像だけど。
すごく消極的だが、前提ライブラリは少なければ少ない方がいい、とか。
Smarty以外にもテンプレートエンジンはあるし、どれも標準にはなり得ない。
最近のFWでもテンプレートエンジンを必須の前提にしていないものが大半だが、
その理由と同じってのでどうだろう。
俺は使えればSmarty使う派だから想像だけど。
数年仕事で使っているが、magic_quotesも、mb_stringの自動変換も、ショートタグも、大半の環境ではオフにされているんだが・・・
実装出来る手段が用意されていて、特別困るものでも無いのに標準機能として盛り込んでしまうと、
裏側の処理を理解していないゆとりPGが泥沼にはまるのが目に見えるわ・・・
そもそもPHPはHTMLを出力するためだけのモノでも無いし、
HTML出力に関しても100%エスケープが必要なものでもない。
実装出来る手段が用意されていて、特別困るものでも無いのに標準機能として盛り込んでしまうと、
裏側の処理を理解していないゆとりPGが泥沼にはまるのが目に見えるわ・・・
そもそもPHPはHTMLを出力するためだけのモノでも無いし、
HTML出力に関しても100%エスケープが必要なものでもない。
>>91
> 大半の環境ではオフにされているんだが・・・
これらがデフォルトになったのはごく最近の話って認識なんだが。
register_globalsだけが少し早かったと。
実際今までだってここら辺に嵌るのがある意味通過儀礼のようなもんだっただろｗ
んで、逆にそういう知識が常識として定着した現状なら、いろんな機能がついてても
それほど問題にもなるまいという風に考えてしまうな
> 大半の環境ではオフにされているんだが・・・
これらがデフォルトになったのはごく最近の話って認識なんだが。
register_globalsだけが少し早かったと。
実際今までだってここら辺に嵌るのがある意味通過儀礼のようなもんだっただろｗ
んで、逆にそういう知識が常識として定着した現状なら、いろんな機能がついてても
それほど問題にもなるまいという風に考えてしまうな
デフォルトでエスケープするのは、いろんなテンプレートエンジンでもそういう機能がある。PHP自体にあってもいいと思う。<?=を別のマクロにすればいいんだろ。エスケープし損なうぐらいなら、余計なエスケープしてしまった方が安全だから。
つうか、まだ懲りずにSmartyを使っているやつがいるんだね。あおりぬきで驚かされる。
php5.3RC2がでたようだけど、5.3になってから
これからのフレームワークは具体的にどう変化するの？
これからのフレームワークは具体的にどう変化するの？
namespaceを使うものが出てくるくらいか？
それだけではそんなに変わりそうな気もしない
何より、フレームワークはあんまりすぐには新バージョンに追随しないと思う
それだけではそんなに変わりそうな気もしない
何より、フレームワークはあんまりすぐには新バージョンに追随しないと思う
late static bindingsの導入で静的メソッド主体のユーティリティクラスを
継承して拡張するのは楽になりそう。
継承して拡張するのは楽になりそう。
>>97
これか
ttp://jp2.php.net/lsb
self::、parent:: に static:: が加わるってことでいいのかな。
しかしこれを読んだだけでは、parent::のstatic::バージョンも欲しくなりそう。
無いって事は、普通はいらないってことなのだろうか。
これか
ttp://jp2.php.net/lsb
self::、parent:: に static:: が加わるってことでいいのかな。
しかしこれを読んだだけでは、parent::のstatic::バージョンも欲しくなりそう。
無いって事は、普通はいらないってことなのだろうか。
99 ：nobodyさん：2009/05/12(火) 06:50:24 ID:V/2qAUy/
singletonオブジェクトの初期化パラメータってどう渡す？
・最初のgetInstance時に初期化パラメータを渡す
・staticなsetXXメソッドを実装して初期値を渡す
選択肢としてはこんくらい？
・最初のgetInstance時に初期化パラメータを渡す
・staticなsetXXメソッドを実装して初期値を渡す
選択肢としてはこんくらい？
インスタンス取ってからすべきでは？
なるほど
コンストラクタでの初期化にこだわってたけど
その方がキレイかも・・ありがとう
コンストラクタでの初期化にこだわってたけど
その方がキレイかも・・ありがとう
102 ：nobodyさん：2009/05/12(火) 13:04:35 ID:WVFMmzYl
そろそろ、yiiの日本語書籍とか出ても言い頃じゃないの？
公式とyiidocで間に合ってる気はする
>>94
なんに懲りるの
なんに懲りるの
105 ：nobodyさん：2009/05/15(金) 20:00:09 ID:wv3qSkZj
フレームワーク本出ますよ。ご丁寧にCodeIgniterまで。
http://www.shuwasystem.co.jp/products/7980html/2277.html
http://www.shuwasystem.co.jp/products/7980html/2277.html
掌田津耶乃ってまだ生きてたんだな
PHPを一通り使えるようになった人向けのPHPフレームワークの入門書です。
フレームワークは、Webアプリケーションの全体構造の仕組みを提供し、
プログラマが書くべきコード量を減らしてくれます。
特に複雑で大規模なアプリケーションになるほど効果は大きくなります。
本書では、注目のPHPフレームワーク4種
（CakePHP/Zend Framework/symfony/Codelgniter）の基本を解説。
MVC（モデル、ビュー、コントローラー）アーキテクチャの基礎のほか、
データベース接続やバリデーションの方法や各フレームワークの特徴がわかりますので、
自分の開発するWebアプリケーションに必要なフレームワークを比較・選択することができます。
各フレームワークを収録したCD-ROM付き。
---
注目…？
フレームワークは、Webアプリケーションの全体構造の仕組みを提供し、
プログラマが書くべきコード量を減らしてくれます。
特に複雑で大規模なアプリケーションになるほど効果は大きくなります。
本書では、注目のPHPフレームワーク4種
（CakePHP/Zend Framework/symfony/Codelgniter）の基本を解説。
MVC（モデル、ビュー、コントローラー）アーキテクチャの基礎のほか、
データベース接続やバリデーションの方法や各フレームワークの特徴がわかりますので、
自分の開発するWebアプリケーションに必要なフレームワークを比較・選択することができます。
各フレームワークを収録したCD-ROM付き。
---
注目…？
PHPではグローバル変数を使え。PHPにシングルトンなんて全く実利が無い。IISやJavaなら実利がある。使いたければPHP止めろ。
>>109
PHP5でコンストラクタもプライベートに出来るようになったし、
staticなメンバ変数も保持できるようになったわけだし、
実利がまったくないってことないんじゃない？
ライブラリ作った場合にライブラリ側で
そのオブジェクトは常に一つしか作成されないのかどうかを出来るっていうのも
ポイントだとおもうけど。
PHP5でコンストラクタもプライベートに出来るようになったし、
staticなメンバ変数も保持できるようになったわけだし、
実利がまったくないってことないんじゃない？
ライブラリ作った場合にライブラリ側で
そのオブジェクトは常に一つしか作成されないのかどうかを出来るっていうのも
ポイントだとおもうけど。
>IISやJavaなら実利がある
>PHPではグローバル変数を使え。
の二言で全て台無し。
コンストラクタをプライベートにするもよし、
コンストラクタ内でstaticインスタンスの存在をチェックして、例外を投げるとかで実装上さほど問題無い。
（マジックメソッド系も実装必要ね）
>PHPではグローバル変数を使え。
の二言で全て台無し。
コンストラクタをプライベートにするもよし、
コンストラクタ内でstaticインスタンスの存在をチェックして、例外を投げるとかで実装上さほど問題無い。
（マジックメソッド系も実装必要ね）
ま、あんまり意味ないのは確か。
PHP歴4年。
グローバル変数ほとんど使った事無い
グローバル変数ほとんど使った事無い
クラスのプロパティ使ってアクセスするより、
グローバル変数使ってアクセスしたほうが速かったような気がするんだが、どうなんだっけ。
グローバル変数使ってアクセスしたほうが速かったような気がするんだが、どうなんだっけ。
116 ：名無し募集中。。。：2009/05/17(日) 17:50:22 ID:wjR/zk6c
仮にそうだとしてもバグの修正は10倍遅くなるぜ
よく言われてるのはグローバル変数じゃなくてローカル変数ね。
プロパティよりローカル変数にアクセスするほうが速いのは確かなんだけど
マイクロベンチマークで「こんなに違うんですよ」と言えるだけで
実際のアプリケーションの動作からすると誤差の範囲でしかない。
プロパティよりローカル変数にアクセスするほうが速いのは確かなんだけど
マイクロベンチマークで「こんなに違うんですよ」と言えるだけで
実際のアプリケーションの動作からすると誤差の範囲でしかない。
$_SESSIONや$_REQUEST、みんな使ってるだろ。オブジェクトにすると面倒だけど、ハッシュならprint_rで一発で目視出来る。
objectにキャストすればおｋ
120 ：名無し募集中。。。：2009/05/18(月) 01:30:21 ID:wP2DRNT9
>>118
みんなが言ってるグローバル変数ってそのことじゃないと思うぞ
みんなが言ってるグローバル変数ってそのことじゃないと思うぞ
わらたｗ
つか、グローバル変数云々の問題って
複数人がかかわるようなもの作ったり、いろんなものを組み合わせて使ったり
そういうときに名前(変数名)がぶつかって不具合でる可能性がないようにするため
クラスぷろぱてーやらローカル変数やら使おうって話でしょ
すべてを一人で把握するような規模でかつ独立してるもんを想定してるんなら
グローバルだろうが問題ないとはおもうよ。わしはやらんが
だいたいそんなしょっぱい規模のものだったらフレームワークとは無縁ｗ
つか、グローバル変数云々の問題って
複数人がかかわるようなもの作ったり、いろんなものを組み合わせて使ったり
そういうときに名前(変数名)がぶつかって不具合でる可能性がないようにするため
クラスぷろぱてーやらローカル変数やら使おうって話でしょ
すべてを一人で把握するような規模でかつ独立してるもんを想定してるんなら
グローバルだろうが問題ないとはおもうよ。わしはやらんが
だいたいそんなしょっぱい規模のものだったらフレームワークとは無縁ｗ
そんなことみんな分かってるんじゃないかな？かな？
先頭が_ですべて大文字で記述するってルールにすればぶつかるわけがない。PHP自体がそういうグローバル変数を初めから持ってるんだから。
意味が分からない
「ぶつかるわけがない」と思ってる奴が他にもいたらぶつかるだろ
「ぶつかるわけがない」と思ってる奴が他にもいたらぶつかるだろ
グローバルとスーパーグローバルは分けて語ろうな
問題は$GLOBALSというスーパーグローバル変数があってだな。
でも、むしろこっち使ってもらう方が何かといいかｗ
でも、むしろこっち使ってもらう方が何かといいかｗ
グローバル変数だらけのソースを
保守する人のことも考えて。
保守する人のことも考えて。
関数やメソッド内で毎回global 宣言するんすかｗ
ｈ
それなりの規模でグローバル変数を多様しないといけないものを作ってしまう時点で
技量不足知識不足と宣言してるも同義
まともなPGなら意図的にそんなことやる意味ないことくらい理解してる
技量不足知識不足と宣言してるも同義
まともなPGなら意図的にそんなことやる意味ないことくらい理解してる
グローバル変数をなくしたら、今度は大量の引数を要求する関数がうじゃうじゃと(ry
それは密結合すぎ
>>131
配列、オブジェクト、クラスを引数として渡せば解決ですね。
配列、オブジェクト、クラスを引数として渡せば解決ですね。
メンバ変数が大量にあるデブクラス
引数の多い関数/メソッドに関しては
クラス引数≧配列引数≧普通の引数＞＞＞グローバル変数
で書くべきだな。
グローバル変数を引数として扱うメリットって何なの？
デフォルト値とか型チェックとか面倒な事しか思い浮かばないんだが・・・
クラス引数≧配列引数≧普通の引数＞＞＞グローバル変数
で書くべきだな。
グローバル変数を引数として扱うメリットって何なの？
デフォルト値とか型チェックとか面倒な事しか思い浮かばないんだが・・・
横断的な変数やオブジェクトの格納じゃないか
ログとか全体的な設定とか
ログとか全体的な設定とか
どうしてもグローバル変数を使いたかったら、$GLOBALSを使えばいいのに。
それなら却って、クラス変数やシングルトンなんかでごにょごにょするよりは
PHPのうまみがあるかも。
すくなくともglobal 変数名よりは反感も少ないだろうし、使ってるうちに少しは
多用に疑問も感じるはず。
それなら却って、クラス変数やシングルトンなんかでごにょごにょするよりは
PHPのうまみがあるかも。
すくなくともglobal 変数名よりは反感も少ないだろうし、使ってるうちに少しは
多用に疑問も感じるはず。
$_なんちゃらのスーパーグローバルなやつらみたいにホイホイ使えるからいいんだよｗ
というか、グローバル禁止ならそいつらもオブジェクトにでも詰め込んでそれを引数にして関数を呼べよと。
というか、グローバル禁止ならそいつらもオブジェクトにでも詰め込んでそれを引数にして関数を呼べよと。
で、グローバル変数を使ってる or 推奨しているフレームワークってあるの？
グローバル定数の代替え手段を理解していない素人が喚いているだけ？
グローバル定数の代替え手段を理解していない素人が喚いているだけ？
>>140
フレームワークの話題でなければスレ違い、って意図だと解釈しておく。
配布されているような汎用フレームワークでは、さすがにグローバル変数は使えないだろう。
ただ、そこら辺で実稼働してるような俺流フレームワークなどの規模や必要性なら、
ガチで原理主義なOOPコーディング（っぽいもの）なんかより、読みやすく
手入れしやすいグローバル変数の使い方もできるだろうし、されてるかもね。
要は使い方だって。
フレームワークの話題でなければスレ違い、って意図だと解釈しておく。
配布されているような汎用フレームワークでは、さすがにグローバル変数は使えないだろう。
ただ、そこら辺で実稼働してるような俺流フレームワークなどの規模や必要性なら、
ガチで原理主義なOOPコーディング（っぽいもの）なんかより、読みやすく
手入れしやすいグローバル変数の使い方もできるだろうし、されてるかもね。
要は使い方だって。
>ガチで原理主義なOOPコーディング（っぽいもの）なんかより、読みやすく
>手入れしやすいグローバル変数の使い方もできるだろうし、されてるかもね。
全く想像つかんｗ
複数人で開発した際に変数名の競合を防げなかったり、
引数としての型チェックやデフォルト値が設定出来ないわけだが…
コーディング規約を徹底管理すれば何とかなるが、
後者はテストを含め、実装には無駄な手間がかかるだろう。
ロジックや変数の局所化はOOP以前の話だと思う。
>手入れしやすいグローバル変数の使い方もできるだろうし、されてるかもね。
全く想像つかんｗ
複数人で開発した際に変数名の競合を防げなかったり、
引数としての型チェックやデフォルト値が設定出来ないわけだが…
コーディング規約を徹底管理すれば何とかなるが、
後者はテストを含め、実装には無駄な手間がかかるだろう。
ロジックや変数の局所化はOOP以前の話だと思う。
>>142
だから、$_POSTやら$_GETやら$_COOKIEにどこからでも代入出来る時点で、
変数の局所化なんて崩れてるって。
# こいつらを最初にいちいちコピーして空っぽにするのが最近は普通なのかな？
なんで「グローバル変数を使う」 ＝ 「無制限に読み書きする」に直結するんだろう。
読むだけなら何の問題もないって。
規約って言ったって、（決まってる初期処理以外で）$GLOBALSに代入する奴は死刑、
ってだけでいいじゃないか。あくまで、$GLOBALSのみ使うっていう前提だけど。
俺はまあまず使わんけど、便利そうな使い方は想像できなくもないよ。
だから、$_POSTやら$_GETやら$_COOKIEにどこからでも代入出来る時点で、
変数の局所化なんて崩れてるって。
# こいつらを最初にいちいちコピーして空っぽにするのが最近は普通なのかな？
なんで「グローバル変数を使う」 ＝ 「無制限に読み書きする」に直結するんだろう。
読むだけなら何の問題もないって。
規約って言ったって、（決まってる初期処理以外で）$GLOBALSに代入する奴は死刑、
ってだけでいいじゃないか。あくまで、$GLOBALSのみ使うっていう前提だけど。
俺はまあまず使わんけど、便利そうな使い方は想像できなくもないよ。
って書いて、なんかわかってきた。
自分がそう思うのは、関数（メソッド）の外でスクリプトを書くって事がないからか。
もう全部、下敷きのディスパッチャがある環境でしかスクリプト書かないし、
トップレベルのスコープで書かれた部分って数枚で、増えない。
もしトップレベルでいろいろ書く必要があるなら、グローバル変数に
代入しないわけにはいかないか。
そうなると、さすがにいきなりグローバル変数の参照は怖くてできんわな。
まあどっちにしろ、局所化できるかどうかの話だけだとは思う。
自分がそう思うのは、関数（メソッド）の外でスクリプトを書くって事がないからか。
もう全部、下敷きのディスパッチャがある環境でしかスクリプト書かないし、
トップレベルのスコープで書かれた部分って数枚で、増えない。
もしトップレベルでいろいろ書く必要があるなら、グローバル変数に
代入しないわけにはいかないか。
そうなると、さすがにいきなりグローバル変数の参照は怖くてできんわな。
まあどっちにしろ、局所化できるかどうかの話だけだとは思う。
>だから、$_POSTやら$_GETやら$_COOKIEにどこからでも代入出来る時点で、
>変数の局所化なんて崩れてるって。
言語レベルで周知されている値と、ユーザーグローバル変数を同列には語れないかと。
(素人でも $_POST を上書きしちゃマズイって事くらいは理解しているだろう)
一部の局所化が既に崩れているから、さらに崩して良いという考えかい？
>なんで「グローバル変数を使う」 ＝ 「無制限に読み書きする」に直結するんだろう。
制限事項を規約で作るくらいなら、定数化なりクラス化するのが普通じゃないかね。
言語レベルで制限御出来る機構が提供されているのに、それを使わない理由がわからない。
>変数の局所化なんて崩れてるって。
言語レベルで周知されている値と、ユーザーグローバル変数を同列には語れないかと。
(素人でも $_POST を上書きしちゃマズイって事くらいは理解しているだろう)
一部の局所化が既に崩れているから、さらに崩して良いという考えかい？
>なんで「グローバル変数を使う」 ＝ 「無制限に読み書きする」に直結するんだろう。
制限事項を規約で作るくらいなら、定数化なりクラス化するのが普通じゃないかね。
言語レベルで制限御出来る機構が提供されているのに、それを使わない理由がわからない。
全然関係ないけど、CodeIgniterは$_GETを空にするよね。
全然関係ないけどね。
全然関係ないけどね。
結局自分がやってるお仕事のせまい範囲でかたってる人がいただけだったというオチ
しかもフレームワークそんな関係ない
しかもフレームワークそんな関係ない
いや、フレームワーク使ってるからこそ、グローバル変数容認論が出るんじゃないかと
そういう意味では関係ある、ような無いような
そういう意味では関係ある、ような無いような
PEARは使ってるな
まぁ、使いまわしをする前提で作成したライブラリにグローバル変数使うのは避けたいかな。
変なオブジェクト（ビューから呼べないとか）使わされるより、$_REQUESTや$_SESSION使った方がいい。
152 ：名無し募集中。。。：2009/05/20(水) 02:19:49 ID:by98XaTN
なんで渡されるのが変なオブジェクト前提なのか解らんが
Viewからrequestやsessionなんて呼ばないだろ。
>>151
もう一度MVCを勉強した方がよくね？
もう一度MVCを勉強した方がよくね？
数年使った事ないと書いたモノだが...
サービスロケーターを実現するために、他のクラスに依存しないということにおいてグローバル変数は有用だと思う。
PEARが使ってるのもそういう理由じゃないかな。
スコープがグローバルなのはクラス名も同じ。名前衝突解決法も同じで良いと思うしPEARもそうしてる。
サービスロケーターを実現するために、他のクラスに依存しないということにおいてグローバル変数は有用だと思う。
PEARが使ってるのもそういう理由じゃないかな。
スコープがグローバルなのはクラス名も同じ。名前衝突解決法も同じで良いと思うしPEARもそうしてる。
クラスだと名前衝突が起きた場合にPHP側が警告してくれる。
グローバル変数だと知らぬ内に値が書き換えられる可能性がある。
この差は大きいと思うので、極力クラス化している。
グローバル変数だと知らぬ内に値が書き換えられる可能性がある。
この差は大きいと思うので、極力クラス化している。
クラスだと関連する定数持たせたりできるしな
グローバル変数なんて石ころみたいなもん
グローバル変数なんて石ころみたいなもん
PHP標準のセッション管理やクエリーパラメーター管理は、連想配列のグローバル変数。皆これを使ってる。それで十分だから。
もしPHPのデベロッパーがセッション管理をオブジェクトにすることが有意と思ってるなら、組み込みクラスを実装してるだろう。
が、そんなことしてもメリットは薄いし、初心者に優しいPHPの良さを消すことになる。ので、PHPのセッション管理は連想配列のまま。
が、そんなことしてもメリットは薄いし、初心者に優しいPHPの良さを消すことになる。ので、PHPのセッション管理は連想配列のまま。
だからこそフレームワークがあるわけだが。
>>159
クラスオブジェクト作るときってただ単純にセッションを管理したいってだけで作るわけじゃないだろ。
ある一定の目的が定義されてて、その定義にあわせて管理することを考えたときに
一つの意味の集合であるクラスを作るのであって。
PHPのデベロッパーはセッション管理をすることの意味なんて凄く広義的に考えて設定してるから、
グローバルな連想配列になってんじゃないのか。
クラスオブジェクト作るときってただ単純にセッションを管理したいってだけで作るわけじゃないだろ。
ある一定の目的が定義されてて、その定義にあわせて管理することを考えたときに
一つの意味の集合であるクラスを作るのであって。
PHPのデベロッパーはセッション管理をすることの意味なんて凄く広義的に考えて設定してるから、
グローバルな連想配列になってんじゃないのか。
そもそも、PHPのスーパーグローバルを否定してる奴はいなくね？
ユーザが勝手に作るグローバル変数をスーパーグローバル変数と同列で語るのがおかしいわけで…
ユーザが勝手に作るグローバル変数をスーパーグローバル変数と同列で語るのがおかしいわけで…
「ユーザが勝手に作るグローバル変数」が問題になるのは、
結局、仕様書だの会社で規定されてる命名規則だの何だのとかきちんとしてないのに
>>109のようなことをつぶやいて>>127のような人を量産する場合なんだろ。
結局オープンソースだとか使いまわし前提のライブラリだのでそんなの使ってると後で使う人が困ったことになるってだけで。
結局、仕様書だの会社で規定されてる命名規則だの何だのとかきちんとしてないのに
>>109のようなことをつぶやいて>>127のような人を量産する場合なんだろ。
結局オープンソースだとか使いまわし前提のライブラリだのでそんなの使ってると後で使う人が困ったことになるってだけで。
スーパーグローバル変数をグローバル変数と勘違いしている輩に振り回されるだけじゃない？
グローバル変数主張してる人はメリットばかりでデメリットをあげないからなぁ、
単なる素人発言にしか見えないんだわ。
実際になんらかのフレームワークを使った上で、
グローバル変数のメリットデメリットを比較してみてくれよ。
単なる素人発言にしか見えないんだわ。
実際になんらかのフレームワークを使った上で、
グローバル変数のメリットデメリットを比較してみてくれよ。
定数はどうなの？
定数もグローバル(define)じゃなくてクラス定数にしてんの？
定数もグローバル(define)じゃなくてクラス定数にしてんの？
defineは使わん
定数と変数じゃ用途が大分用途が違うしなぁ
使ったとしても最低限のフラグ程度にしか使わないし
DEBUG_MODE とか、そんな感じのやつ。接頭子もつけてる。
クラスに関する定数は、当然クラス定数にしているよ。
使ったとしても最低限のフラグ程度にしか使わないし
DEBUG_MODE とか、そんな感じのやつ。接頭子もつけてる。
クラスに関する定数は、当然クラス定数にしているよ。
作りすぎなければ良いだけのこと。まあ、たくさん作ったとしても、どうせリクエストの度に消滅するんだから、それほど気にすることもないが。
リクエスト内で競合する可能性が問題視されてるのでは？
171 ：nobodyさん：2009/05/21(木) 10:34:56 ID:HWozpBcz
>>109に釣られ過ぎだろ
いや、それ以下か。シングルトンいらんって話が、引数を渡すのにとか名前がぶつかるからって話にダウングレードしてるし
いや、それ以下か。シングルトンいらんって話が、引数を渡すのにとか名前がぶつかるからって話にダウングレードしてるし
定数を多重定義したらエラーが表示される。
173 ：nobodyさん：2009/05/21(木) 14:55:07 ID:P779ZgB3
最近、はてな界隈ではCakePHPとSymfonyの話ばっかりだよ。
あいつら、ZendFrameworkやCodeIgniterの事なんて気にもしてないよ。
あいつら、ZendFrameworkやCodeIgniterの事なんて気にもしてないよ。
>>173
たんなる感だけど、日本で流行らないのは名前の文字数のせいだと思ってるｗ
たんなる感だけど、日本で流行らないのは名前の文字数のせいだと思ってるｗ
175 ：nobodyさん：2009/05/21(木) 16:23:26 ID:P779ZgB3
>>174
マジでwww！！？
マジでwww！！？
PerlよりRubyよりもちろんJavaよりも短いPHPやっぱり最強だな
比較的大きな案件ならCodeigniterなんて論外だろ。
なんで？
だいたい、どれくらいで「大きな案件」よ
はてな住人はそんなにみんな大きな案件ばっかりやってるのか？
だいたい、どれくらいで「大きな案件」よ
はてな住人はそんなにみんな大きな案件ばっかりやってるのか？
いざって時に情報や技術者が少ないと困るからじゃね？
Codeigniter出来る人を求人してもいなさそうなイメージ…。
Codeigniter出来る人を求人してもいなさそうなイメージ…。
180 ：nobodyさん：2009/05/21(木) 22:34:08 ID:P779ZgB3
phaだって、CakePHP使ってるんだぞ！
CodeIgniter(笑)
うまく説明できないけど、CodeIgniterはないと思うに一票。
CodeIgniterは、コア部分とかをオーバーライドして簡単に修正出来るのと
実際公式サイトに書いてあるように習得が楽なので、ないこたないと思うけど？
バリデータがしょぼかったから別の使ってるけど。
まぁ、一人で適当にアプリ作るには割りとちょうどいいかな。
階層も薄いからどこでどう動いてるかとかも把握しやすいし。
実際公式サイトに書いてあるように習得が楽なので、ないこたないと思うけど？
バリデータがしょぼかったから別の使ってるけど。
まぁ、一人で適当にアプリ作るには割りとちょうどいいかな。
階層も薄いからどこでどう動いてるかとかも把握しやすいし。
184 ：名無し募集中。。。：2009/05/22(金) 00:30:33 ID:f3nFju+F
グループ開発になるとZend,Symfony,Cake,Ethnaくらいしか選択肢ないよ
それ以外は経験者集められない
それ以外は経験者集められない
185 ：nobodyさん：2009/05/22(金) 00:55:57 ID:RzyQ8gRW
>>184
ありすぎて、問題だなｗ
ありすぎて、問題だなｗ
なんでコードまで読めなくなるんだよｗ
なんだかんだでZendブランドは強い。
>>186
せめて名前が、Code Igniter だったらまだマシだったのかｗ
せめて名前が、Code Igniter だったらまだマシだったのかｗ
191 ：nobodyさん：2009/05/22(金) 12:25:09 ID:RzyQ8gRW
yiiとかどうなの？
なるほど、じゃぁ文字数的にはやっぱりCが最強なんだな。
Cって検索するとき困る
付き合うならDぐらいは欲しいな
196 ：nobodyさん：2009/05/23(土) 11:28:31 ID:sw/qjhoP
Dと付き合ってるけど毎年性格が豹変するから疲れる
そこで颯爽とR登場。マニアックな魅力にみんなイチコロ（死語）
エラー表示が優れてるフレームワークはどれ?
php
200 ：nobodyさん：2009/05/24(日) 01:25:18 ID:UrsSuZGN
>>198
Cakeじゃね？DBのクエリーを見れるじゃん。
Cakeじゃね？DBのクエリーを見れるじゃん。
クエリー出るのはいいね
SQLクエリのエラー表示、ってだけで見るのもどうかと
PHP5に特化して統一されたエラーハンドリングができる方がフレームワークとしてはいいかもよ。
SQLのエラー（例外）をキャッチできればクエリ出すことも簡単だろうし。
ZFやらKohanaとかもいいんでね？面倒なのでやってないけど。
PHP5に特化して統一されたエラーハンドリングができる方がフレームワークとしてはいいかもよ。
SQLのエラー（例外）をキャッチできればクエリ出すことも簡単だろうし。
ZFやらKohanaとかもいいんでね？面倒なのでやってないけど。
その面倒がだめなんでしょ
うん。なるほど。納得
ZFはDBアダプタにプロファイラ設定するだけで、
クエリから実行時間まで全てログれる件。
表向きに簡単！便利！と売るより、
プログラマにとって地味に嬉しい機能を全面に出すフレームワークは無いものかね
クエリから実行時間まで全てログれる件。
表向きに簡単！便利！と売るより、
プログラマにとって地味に嬉しい機能を全面に出すフレームワークは無いものかね
>>205
地味に嬉しい機能って何?
地味に嬉しい機能って何?
207 ：nobodyさん：2009/05/25(月) 00:28:25 ID:n6zT/Oby
ZendもCakeもSymfonyも表向きだけじゃなくてプログラマ向けに便利だと思うけど
208 ：nobodyさん：2009/05/25(月) 00:44:44 ID:3dtn4t5a
> getQuery() は、クエリの SQL テキストを返します。
パラメータつきのプリペアドステートメントの場合、 クエリがプリペアされた時点のテキストを返します。
つまり、プレースホルダを含んだままの形式ということです。
実行時に置き換えられた値を知ることはできません。
orz
パラメータつきのプリペアドステートメントの場合、 クエリがプリペアされた時点のテキストを返します。
つまり、プレースホルダを含んだままの形式ということです。
実行時に置き換えられた値を知ることはできません。
orz
Perlの場合、フレームワークとか関係無しに、DBI経由でSQLをダンプできる。
211 ：nobodyさん：2009/05/25(月) 05:32:16 ID:n6zT/Oby
それはPHPでもなんでも出来るので
perlすごいな
PHPは捨てることになします
ありがとうございました
PHPは捨てることになします
ありがとうございました
さようなら
文盲はもう帰ってこなくていいよ
文盲はもう帰ってこなくていいよ
PHPの組み込みDB関数にSQLのダンプ機能ってあるのか？
あるんじゃない？必要ないから使ったことはないけど。
どうやるの？php.iniで設定するとか、コネクション張るときに引数に渡すとか
ひょっとしてDBのログをtailfで見ている俺は勝ち組?
>>200
それsymfonyからパクった機能じゃん
それsymfonyからパクった機能じゃん
静かだな。
なんかネタない〜？
なんかネタない〜？
アンケートでもするかー
1 今使用してるフレームワーク
2 使用した事のあるフレームワーク
3 それぞれの寸評または10点満天でのスコア
4 欲しい機能
どぞ
1 今使用してるフレームワーク
2 使用した事のあるフレームワーク
3 それぞれの寸評または10点満天でのスコア
4 欲しい機能
どぞ
222 ：名無し募集中。。。：2009/06/09(火) 00:24:43 ID: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 欲しい機能
日本のガラパゴス携帯に簡単に対応して欲しい
無理だろうけど
個人ではCakePHPとZendFramework
仕事で他人が作ったSymfonyのシステムもいじる
2 使用した事のあるフレームワーク
Ethna
Mojavi
Maple
CakePHP
ZendFramework
Symfony
3 それぞれの寸評または10点満天でのスコア
Ethna 8点 かなり良いけど今使うには古い
Maple,Mojavi 初期構築やってないんであんま記憶ない
CakePHP 9点 初期構築なら一番開発が楽
ZendFramework 7点 自由すぎで楽はできない
Symfony 5点 これしか知らなかったらこれでいいけど、他知ってると荒が見えてしまう
4 欲しい機能
日本のガラパゴス携帯に簡単に対応して欲しい
無理だろうけど
MOONGIFT: ? Sinatraを真似たPHP用軽量フレームワーク「Fitzgerald」
http://www.moongift.jp/2009/06/fitzgerald/
簡単なURLマッピング、シンプルなレスポンス。どれをとっても簡単だ。
そんなSinatraを真似たPHP用フレームワークがFitzgeraldだ。
http://www.moongift.jp/2009/06/fitzgerald/
簡単なURLマッピング、シンプルなレスポンス。どれをとっても簡単だ。
そんなSinatraを真似たPHP用フレームワークがFitzgeraldだ。
225 ：nobodyさん：2009/06/09(火) 09:36:31 ID:g6/5Uspu
codeigniter使ってる人いないの？
ZendFW導入して3ヶ月。だいぶコード書くのが楽になってきた。
構造がしっかりするのは良いもんだね。
構造がしっかりするのは良いもんだね。
セッション周りで自作って致命的だな。
え？
CodeIgniter(笑)
こでいｇにてぁ？(*‘ω‘ *)？
そこでkohanaですよ
んだ。
メジャー所一通り経由したが、kohanaは見通しよくてよい。
メジャー所一通り経由したが、kohanaは見通しよくてよい。
いらね
フレームワークに一番期待するものを述べよ
おれはDBラッパーが使いやすけりゃいいかな
おれはDBラッパーが使いやすけりゃいいかな
フロントコントローラとディスパッチ先の管理
>>222がいってる、携帯対応は欲しいね。
後はHTMLデザイン関連フレームワークが同梱されてるようなものとか
あるといいなぁって思った。
Webサイトを作成するって段階において、一人で全部作成しようとすると
管理画面含め、画面作成部分が実は凄く面倒くさい。
まぁ、YUIとかそこらへんのCSSフレームワークとかを使えってことなのかもしんないけど。
後はHTMLデザイン関連フレームワークが同梱されてるようなものとか
あるといいなぁって思った。
Webサイトを作成するって段階において、一人で全部作成しようとすると
管理画面含め、画面作成部分が実は凄く面倒くさい。
まぁ、YUIとかそこらへんのCSSフレームワークとかを使えってことなのかもしんないけど。
携帯対応ってどんな？
絵文字<->絵文字変換
絵文字->画像変換
GET/POST文字コード自動変換
文字コード変換出力
ほかは？
絵文字<->絵文字変換
絵文字->画像変換
GET/POST文字コード自動変換
文字コード変換出力
ほかは？
IP・UserAgentでの判別
クッキー使えないときのセッション管理
クッキー使えないときのセッション管理
組み込みのWEB管理画面が欲しいな、
phpMySQLAdminみたいな感じで、FWの情報を見たり、設定を変更出来たり、
各種設定が変更でたり、モジュールのユニットテスト支援してくれたい、etc
初期導入が楽なものより、
デバッグ機能が充実かつ容易な物が欲しい。
phpMySQLAdminみたいな感じで、FWの情報を見たり、設定を変更出来たり、
各種設定が変更でたり、モジュールのユニットテスト支援してくれたい、etc
初期導入が楽なものより、
デバッグ機能が充実かつ容易な物が欲しい。
>>240
そうそうそういうのいいね
そうそうそういうのいいね
普通はつけるよな
PEARパッケージにもできないし
PEARパッケージにもできないし
http://slashdot.jp/security/article.pl?sid=09/06/23/0455215
Apacheに新たな脆弱性が発見されてPHPたちまち脂肪ｗｗｗ
Apacheに新たな脆弱性が発見されてPHPたちまち脂肪ｗｗｗ
>>245
ネートは不幸な生育環境で非行に走っただけで元々の性質は悪くないだろ
変わったのではなく矯正施設の教育で本人の良さが引き出されただけ
ニートは成人するまで両親揃って何不自由なく育ったのに親掛かりを悪びれる素振りもない
人間そのものを変えるなんて事はどだい不可能なんだよ
彼らを何とかしようとするとき共存を考えるよりはそもそも始めからいない物としてカウントしない
そういった方向で何とかする方法を考えた方がいい
ネートは不幸な生育環境で非行に走っただけで元々の性質は悪くないだろ
変わったのではなく矯正施設の教育で本人の良さが引き出されただけ
ニートは成人するまで両親揃って何不自由なく育ったのに親掛かりを悪びれる素振りもない
人間そのものを変えるなんて事はどだい不可能なんだよ
彼らを何とかしようとするとき共存を考えるよりはそもそも始めからいない物としてカウントしない
そういった方向で何とかする方法を考えた方がいい
>>248
生きててごめんなさい ;-;
生きててごめんなさい ;-;
みんな 5.3 入れた?
5.2みたいにパフォーマンスが上がったわけじなくて
変な文法増えただけだろ？
ｲﾗﾈ
変な文法増えただけだろ？
ｲﾗﾈ
そんな餌に釣られるもんですかっ
バックスラッシュな時点で日本ではオワタな感じがする。
半角円記号とBackSlashを同じコードにしたやつはばくはつしてしまえばいい
ぎぎぎ
ぎぎぎ
どこに割り当てればよかったと思う？
考えなしに記号を消費しまくったPHPが悪い。
PHPはそう遠くないうちに終わるだろう
記号消費といえば Perl な印象。
これだけ PHP アプリがあると、COBOL、Java のように負の遺産として残るんだろうなぁ。
これだけ PHP アプリがあると、COBOL、Java のように負の遺産として残るんだろうなぁ。
PHPが何に取って代わるの？
261 ：nobodyさん：2009/08/14(金) 18:51:57 ID:eBpbFkcS
PHP最強ということFAですね
強さは知らんが、PHPのポジションはそれなりに気づいてると思うけどな
言語記法としてはウンコ。
標準機能(extension含む)の手軽さではピカイチ。
言語としては ECMAScript が手軽かつ綺麗なのでいつか主流になると思う。
サーバサイド実装がほとんど無い現状だけども。
標準機能(extension含む)の手軽さではピカイチ。
言語としては ECMAScript が手軽かつ綺麗なのでいつか主流になると思う。
サーバサイド実装がほとんど無い現状だけども。
あんだけ普及してたPerlもいまじゃPHPと入れ替わったわけだし
いつかまた別のが来てもおかしくはないとは思うけど
当分はPHPが死ぬことはないと思うなー
まぁ入れ替わるとしても、風向きが変わってからとりかかりゃいいしな
なんだかんだで今後もあまり発展性のなさそうなものを新たに覚えるよりは
いま使いやすいのを使っておくのが無難かなと思うトコロ
いつかまた別のが来てもおかしくはないとは思うけど
当分はPHPが死ぬことはないと思うなー
まぁ入れ替わるとしても、風向きが変わってからとりかかりゃいいしな
なんだかんだで今後もあまり発展性のなさそうなものを新たに覚えるよりは
いま使いやすいのを使っておくのが無難かなと思うトコロ
PHPは当分残るだろうね。
良くも悪くも現状のWEB開発においては不満が少ないし、十二分に枯れている。
ブラウザとの親和性も含めるとECMAScriptがなんらかのきっかけで爆発的に普及する気がしないでもない。
良くも悪くも現状のWEB開発においては不満が少ないし、十二分に枯れている。
ブラウザとの親和性も含めるとECMAScriptがなんらかのきっかけで爆発的に普及する気がしないでもない。
ECMAScript はライブラリが充実したらいいと思う
Rhino on Railsかね、JSの本命は。
あれが来たらもしかしたら意外とサーバーサイドJS流行る可能性があるかもしれない。
webやるならいずれにせよ多少は触る言語だしね。
あれが来たらもしかしたら意外とサーバーサイドJS流行る可能性があるかもしれない。
webやるならいずれにせよ多少は触る言語だしね。
Rubyは導火線だったけど、爆発物じゃない、みたいな感
CodeIgniterは点火装置
PHPは爆発物では無い、もはや炭みたいなもの。
練炭ですね
炭はむしろほめ言葉だけどなｗ
褒めてるんだよｗ
ここまで手軽で高機能で普及していて枯れているWEB系言語は他に無い。
ここまで手軽で高機能で普及していて枯れているWEB系言語は他に無い。
ガラッと変わってもいいから1度ちゃんと整理してほしいなあｗ
PHP7 か
便利にするには無駄に消費してしまった文字を使った
過去互換機能を切る必要があるからなぁ
ごっそり削ってほしいところがいっぱいあるんだけど、難しいんだろうなぁ
過去互換機能を切る必要があるからなぁ
ごっそり削ってほしいところがいっぱいあるんだけど、難しいんだろうなぁ
過去互換機能を残しても無くしても叩かれるんだからかわいそうね
引数の型指定に、stringとかが指定出来ないのが納得いかねぇんだよぉおおお･･･
設計した奴はまじでウンコ。
設計した奴はまじでウンコ。
PHPではstringやらintにこだわることは意味をなさない
280みたいな人が多いから、PHP使いは見下されるんだよな･･･
厳密な型指定が出来るに越した事は無い。
厳密な型指定が出来るに越した事は無い。
お前は何を言ってるんだ
じゃPHPでない言語使えよ
じゃPHPでない言語使えよ
コンパイル言語なら必要
何故関係無いことを持ち出すのか分かりません
286 ：nobodyさん：2009/08/15(土) 20:30:08 ID:YNZCA/eJ
型指定ができないせいで、かえって型を意識しないといけない、という局面は結構多いと思う。
case 0:とかな。
メリットは大きいが、全体を通してみるとデメリットの方が大きいと思う。
>284
問題はコンパイル言語かどうかじゃない。静的型言語か動的型言語かが問題。
case 0:とかな。
メリットは大きいが、全体を通してみるとデメリットの方が大きいと思う。
>284
問題はコンパイル言語かどうかじゃない。静的型言語か動的型言語かが問題。
PHPの場合は自動型変換がウンコだからデメリットの方がでかい
>>283
>>280が型指定を理解してるとは思えないがｗ
型指定の「強制」はPHP的にありえないには同意。
>>279は引数の型チェックとして型指定が出来るようになったのに、
なぜstringやintが指定できねーんだ･･･糞が！！って事を言いたかった。
だから中途半端で、頭悪そうな言語になっちゃうんだよ！
>>280が型指定を理解してるとは思えないがｗ
型指定の「強制」はPHP的にありえないには同意。
>>279は引数の型チェックとして型指定が出来るようになったのに、
なぜstringやintが指定できねーんだ･･･糞が！！って事を言いたかった。
だから中途半端で、頭悪そうな言語になっちゃうんだよ！
型指定が必要になるような規模のコードはPHPで書かないから問題ない
PHPってめちゃくちゃパーサーがしょぼいよな。print "$var全角"とかで平気でパースエラーが起きる。$varが展開されない。
if とか while とかでブロックのネストが深いところでシンタックスエラー起きると、エラー発生の行数が出ない事もある。
行数じゃなくて行番号だった
行番号が正確に出る言語ってあまり無いような･･･
そもそも if while を深くネストする状況が･･･
そもそも if while を深くネストする状況が･･･
多分機能詰め込みすぎたピザメソドでも書いてんだろう
PHPだって普通は行番号出る。そんなの他の言語でも当たり前。ところが、コードが複雑になってくると、エラーメッセージから行番号が消えて、どこかにエラーがありますって。どういう理屈なのか知らない。
型指定の問題もこういう絶望的な。
http://d.hatena.ne.jp/JULY/20090622/p1
http://d.hatena.ne.jp/JULY/20090622/p1
Javaとか日本語の変数名をつけられるしな。
>>287
そうだ
そうだ
最近は2重ネストですら潰したくなって困る。
3重くらいまでは潰すメリットのが大きいが、この辺まで来ると趣味だな。
3重くらいまでは潰すメリットのが大きいが、この辺まで来ると趣味だな。
型は、ぶっちゃけ指定したくなるときあるな。
32bit機で64bit整数使いたいときがあったりもする。
俺の脳が古いんだろうけどな・・・。
32bit機で64bit整数使いたいときがあったりもする。
俺の脳が古いんだろうけどな・・・。
> 32bit機で64bit整数使いたいときがあったりもする。
32bit機で64bit整数使えない言語なんてあるの？
32bit機で64bit整数使えない言語なんてあるの？
存在するかもしれないけど、現実にそんなもの使う機会はないな
>>306
phpだと、実数になっちゃうじゃん。
phpだと、実数になっちゃうじゃん。
>>306
php -r '$a=pow(2,62);$a++;$b=$a&1;print "$a $b\n";'
32bit機だと 4.6116860184274E+18 0
64bit機だと 4611686018427387905 1
型指定したくなる気持ちも分かる。
php -r '$a=pow(2,62);$a++;$b=$a&1;print "$a $b\n";'
32bit機だと 4.6116860184274E+18 0
64bit機だと 4611686018427387905 1
型指定したくなる気持ちも分かる。
gmpで任意精度整数を扱えるじゃない
扱う数字が32bitの範囲を超えそうだ！
というだけの理由で64bit環境を採用したうちの会社。
というだけの理由で64bit環境を採用したうちの会社。
正しい判断じゃね？
必要ならすればいいがな
PHPでどんなときも型指定が必須だし、したいってのもお門違いだと思うけど。
PHPでどんなときも型指定が必須だし、したいってのもお門違いだと思うけど。
型指定したい時なんてそんなに頻繁にないし
したい時にチェックして例外投げりゃいいじゃん
したい時にチェックして例外投げりゃいいじゃん
チェックで代用できるって言ってるんじゃん
頭固い子だな
頭固い子だな
基本やりたいことが実現するならやりたいようにやればいいけど。
人に強要しだすと面倒くさい。
メリットを強調してくれるならまだしも、趣味を押しつけられても困る。
人に強要しだすと面倒くさい。
メリットを強調してくれるならまだしも、趣味を押しつけられても困る。
誰が強要してるねん
>>320
へ？君の言ってる型指定ってどんなのを言ってるの？
へ？君の言ってる型指定ってどんなのを言ってるの？
リファレンスなりちゃんと用意してりゃ型指定とかしなくてもチェックだけで十分代用できると思うけどなぁ
<?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。
$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。
数値文字列混在させたswitch-caseのcase 0:の不具合はたしかに変な動作だけど
そもそもcase文に数値と文字列を混ぜて使うあたり頭悪いと思う
そもそもcase文に数値と文字列を混ぜて使うあたり頭悪いと思う
<?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 とかでもいい。多少気持ち悪いけど何より手っ取り早い
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 とかでもいい。多少気持ち悪いけど何より手っ取り早い
2を消し忘れてた
もう一年以上まともにPHP触ってないけど、多分これでいけるはず
もう一年以上まともにPHP触ってないけど、多分これでいけるはず
文字列と数値を同じ演算子で比較する、しかも、0始まりの文字列を適当に変換する、無理があったな。
function hoge(string $str, int $int)
{
}
って書けるのと、function内で型チェックして例外投げるのが同じとか言ってる人は頭弱すぎだろ。
強制じゃなく、必要な箇所にだけ型指定出来ればPHPDocも出力出来るし、便利だと思うんだけどね。
{
}
って書けるのと、function内で型チェックして例外投げるのが同じとか言ってる人は頭弱すぎだろ。
強制じゃなく、必要な箇所にだけ型指定出来ればPHPDocも出力出来るし、便利だと思うんだけどね。
いい加減にしろ
おのれでクラス作ってタイプヒンティング書けばいいだろ
つーかPHP使わなきゃいいんじゃね？
そもそもの発端が、>>279 の
型指定の中途半端さに対する指摘だったのに、
なぜ型指定自体の論争になるのか理解出来ない。
出来るに越した事は無いし、PHP以外を使えとかどんだけ盲目信者なんだと。
>>330とか本気でそう思ってるならプログラマ辞めた方がいい。
型指定の中途半端さに対する指摘だったのに、
なぜ型指定自体の論争になるのか理解出来ない。
出来るに越した事は無いし、PHP以外を使えとかどんだけ盲目信者なんだと。
>>330とか本気でそう思ってるならプログラマ辞めた方がいい。
いやだってPHPは文字列も整数も同じように扱えたほうが便利だよねってとこから
言語思想がスタートしてるんだから自分がPHPを選んだ上でそれを言うのは非常にナンセンスかと
言語思想がスタートしてるんだから自分がPHPを選んだ上でそれを言うのは非常にナンセンスかと
入力も出力も文字列だしな
いちいち内部で変換するとかC/C++で嫌なほど苦労した
いちいち内部で変換するとかC/C++で嫌なほど苦労した
自分でextention書けばいいだけ
PHPの型指定に文句言うのは小学生までだよねｷｬﾊﾊｷﾓｰｲ
PHPの型指定に文句言うのは小学生までだよねｷｬﾊﾊｷﾓｰｲ
checkdate()は$_POSTデータ直で渡したら転けた。
微妙にintオンリーとかあるよね。
微妙にintオンリーとかあるよね。
>>333
PHP5でOOPよりに思想が変化したじゃん。
引数として型指定出来るようになって、
それはPHPの良さを保ちつつ、必要な箇所は堅牢に出来るってイメージだったんだけど、
stringとかintを型指定出来ない理由が不明なんだよね。
気持ち悪いとは思わないのかなと。
PHP5でOOPよりに思想が変化したじゃん。
引数として型指定出来るようになって、
それはPHPの良さを保ちつつ、必要な箇所は堅牢に出来るってイメージだったんだけど、
stringとかintを型指定出来ない理由が不明なんだよね。
気持ち悪いとは思わないのかなと。
クラスタイプヒンティングだけで十分だけど
ダックタイピングはむしろ美徳だろ
原始人乙としか言いようがない
原始人乙としか言いようがない
誰もダックタイピングの話なぞしていない
stringやintを型指定できるようにするくらい
コスト的には何でもないように思えるが、しない理由は何なのだろうか？
ユダヤ教徒の宗教上の理由か？
コスト的には何でもないように思えるが、しない理由は何なのだろうか？
ユダヤ教徒の宗教上の理由か？
存在しないクラスStringでタイプヒンティングして
出たエラーをハンドリングして判定したらいいんじゃね？
出たエラーをハンドリングして判定したらいいんじゃね？
is_string / is_int とかあるんだから内部的には型情報持ってる気がするんだけどね。
ネームスペースのバックスラッシュもそうだけど、
何らかの矛盾が生じる実装になっちゃってて技術的に難しいのかもね。
ネームスペースのバックスラッシュもそうだけど、
何らかの矛盾が生じる実装になっちゃってて技術的に難しいのかもね。
どんな型であれ受け取れるのが前提にあるとかそんな感じなんじゃないの
一般的な意味でのオーバーロードもできないんだし
まぁ型チェック程度なら一度値書きゃ使いまわせるし
必ず値がこれだってわかってるなら決め打ってチェックかけなくてもいいしな
例外？しるか、みたいないい加減な実装で、使える値はリファレンス見るか察してくれ
ってのがPHPなんだと思ってる
一般的な意味でのオーバーロードもできないんだし
まぁ型チェック程度なら一度値書きゃ使いまわせるし
必ず値がこれだってわかってるなら決め打ってチェックかけなくてもいいしな
例外？しるか、みたいないい加減な実装で、使える値はリファレンス見るか察してくれ
ってのがPHPなんだと思ってる
そりゃPHPが初心者向けに作られた言語だからだよ。Perlがuse strictを実質的に強制するようになって、一気にユーザが減った。
気持ち悪い
根拠が薄い時に使われる事が多い
根拠が薄い時に使われる事が多い
>>349
論点ずれすぎ。
クラスタイプヒンティング自体が実装されている以上、意味が無いという事は無い。
あと例えが頭悪すぎかつ意味不明。
そんな用途しか思いつかない君には意味が無いのかもしれないな･･･
論点ずれすぎ。
クラスタイプヒンティング自体が実装されている以上、意味が無いという事は無い。
あと例えが頭悪すぎかつ意味不明。
そんな用途しか思いつかない君には意味が無いのかもしれないな･･･
すごい言い様だな
>>349
え？ＰＯＳＴから数値を受け取りたい場合、普通は型チェックしてｉｎｔに変換するよね？
え？ＰＯＳＴから数値を受け取りたい場合、普通は型チェックしてｉｎｔに変換するよね？
HTTPは数値も全て文字列で渡されるからなぁ。
これがC言語であっても、結局は文字列から数値に変換する必要があるわけだ。
手間は何も変わらない。
これがC言語であっても、結局は文字列から数値に変換する必要があるわけだ。
手間は何も変わらない。
あーだこーだ言う前にここ二ヶ月くらいのinternal読んどけ。
型指定否定派はプログラマとしての能力(デバッグ力)が低そうなイメージだな･･･
・privateとかいらないよね！
・interfaceとか何につかうの？ｗ
・abstract？面倒なだけじゃんｗ
・そもそもclass化すると速度遅くなるし！
・テンプレートエンジン？いらねｗ PHP自体がテンプレートエンジンだからｗ
・privateとかいらないよね！
・interfaceとか何につかうの？ｗ
・abstract？面倒なだけじゃんｗ
・そもそもclass化すると速度遅くなるし！
・テンプレートエンジン？いらねｗ PHP自体がテンプレートエンジンだからｗ
残念だがそれらは型指定とは関係ない
あくまでイメージだよ･･･使いこなせないから不要って人がPHP使いには多い気がする
で、他の言語もかじってる人がツッコミを入れると袋だたきにされる･･･と。
で、他の言語もかじってる人がツッコミを入れると袋だたきにされる･･･と。
最初に触った言語がPHPの人ってかわいそうだよね。
その後もプログラマーとして成長できなさそう。
その後もプログラマーとして成長できなさそう。
自分がついていけないから、言語の進化を否定している感じだよね
無名関数とかネームスペースとか、浸透しなさそうだなぁ
無名関数とかネームスペースとか、浸透しなさそうだなぁ
363 ：nobodyさん：2009/08/19(水) 21:13:37 ID:sk0qCFj1
むしろ型指定にうるさいだけの奴の方が初心者くせー
分かりきってること言ってるだけだし
代替案示されてもふてくされる
ただの馬鹿ですね分かります
分かりきってること言ってるだけだし
代替案示されてもふてくされる
ただの馬鹿ですね分かります
コード内で型チェックして例外投げるのが面倒だから、
組み込み型もタイプヒンティングしたいって話じゃないの？
代替え案なんてあったっけ･･･？
組み込み型もタイプヒンティングしたいって話じゃないの？
代替え案なんてあったっけ･･･？
// 型指定あり
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();
}
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();
}
オプションとしてあっても誰も困らないんだから
あった方がいいのは疑問の余地がねーんだよ
ただ文句言ってるだけなのが頭悪い
あった方がいいのは疑問の余地がねーんだよ
ただ文句言ってるだけなのが頭悪い
PHPのマニュアルでは、型指定も戻り値指定もあるんだよねぇ･･･
PHPDocで同様のマニュアルを出力したいんだけど、
現状では@paramに型までキッチリ書かないといけないから面倒すぎる。
PHPDocで同様のマニュアルを出力したいんだけど、
現状では@paramに型までキッチリ書かないといけないから面倒すぎる。
型指定ﾏﾝｾｰ派は、コーディングのときなんかに、決められた型しか渡せないのがわかるから、
バグを作りこむ可能性が少ない、とか、自分が書くメソッドでチェックしなくてすむから便利つってて、
チェック処理でいいだろ派は、渡される値の型がわからないものを処理する場合
メソッド内でチェックするか外でチェックするかの違いしかないから、
結局チェックかませりゃいいだけじゃん
つってる
そこらへんをお互いが理解してないのか知らんけど、話かみ合ってねーだろｗ
つか、指定できれば便利、ってのはみんなわかってるだろう
でもぐだぐだ不満垂れようが、結局いまのPHPじゃできないんだから
ここで愚痴るのも馬鹿な話というかお門違い。フレームワークにも関係ねーし
だいたいそういうのはPHPを使うと決めた時点で割り切るべき機能だと思うけどな
型指定できない仕様が向いてないもの作るなら、まずPHPを選択肢から除外するべきじゃ
バグを作りこむ可能性が少ない、とか、自分が書くメソッドでチェックしなくてすむから便利つってて、
チェック処理でいいだろ派は、渡される値の型がわからないものを処理する場合
メソッド内でチェックするか外でチェックするかの違いしかないから、
結局チェックかませりゃいいだけじゃん
つってる
そこらへんをお互いが理解してないのか知らんけど、話かみ合ってねーだろｗ
つか、指定できれば便利、ってのはみんなわかってるだろう
でもぐだぐだ不満垂れようが、結局いまのPHPじゃできないんだから
ここで愚痴るのも馬鹿な話というかお門違い。フレームワークにも関係ねーし
だいたいそういうのはPHPを使うと決めた時点で割り切るべき機能だと思うけどな
型指定できない仕様が向いてないもの作るなら、まずPHPを選択肢から除外するべきじゃ
お門違いだよ
お門違いじゃないよ
理由を言えよ、たこ助野郎
みんなで芋堀りすればいいんじゃね？
落ちて久しいPHP総合スレたててそっちでやれｗ
>>369
お前がいやだと思ってることはもう十二分にわかったから、日記帳にでも書いてろｗ
お前がいやだと思ってることはもう十二分にわかったから、日記帳にでも書いてろｗ
ちょっと質問なのだけど、
2〜3枚の軽いけど、DBを一応使う。みたいな要件の時FW使うまでもないかなと考えてるのですが、
そういう時皆はどうやって作ってますか？
規模に関係なくFW使ってる？
それとも、pdoとか使ってべた書き？
2〜3枚の軽いけど、DBを一応使う。みたいな要件の時FW使うまでもないかなと考えてるのですが、
そういう時皆はどうやって作ってますか？
規模に関係なくFW使ってる？
それとも、pdoとか使ってべた書き？
>>355
ああ、それは大きいな。しょせんHTTP（というかHTML）には限界がある。
try {
int $num = $_REQUEST['age'];
} catch (Exception $e) {
die("age is not number");
}
こういうのがベスト。連想配列とかオブジェクトを直接REQUEST出来たり名。
ああ、それは大きいな。しょせんHTTP（というかHTML）には限界がある。
try {
int $num = $_REQUEST['age'];
} catch (Exception $e) {
die("age is not number");
}
こういうのがベスト。連想配列とかオブジェクトを直接REQUEST出来たり名。
phpとかhttpとか限界じゃなくて仕様と割り切るのが精神衛生上いいし、そういうもんじゃないのか
コツコツと自前の関数郡作ってる
そして会社には絶対に持っていかない
そして会社には絶対に持っていかない
>>379
小さいプロジェクトはいいな。
小さいプロジェクトはいいな。
>>379 のコードが理解出来ないのは俺だけか
Integer型の $num に Integer 以外の型で値が渡ってきたら
おかしいことなので例外が発生。
そのとき「値がおかしいぜ！」ってダイイングメッセージ残して
phpが死ぬって意味だろ。
しかしせめて
int $num = Integer.parseInt($_REQUEST['age']);
とかだろ。
おかしいことなので例外が発生。
そのとき「値がおかしいぜ！」ってダイイングメッセージ残して
phpが死ぬって意味だろ。
しかしせめて
int $num = Integer.parseInt($_REQUEST['age']);
とかだろ。
例外の使い方が不適切なような・・
想定外の値が来たからキャストエラーだろ？
何か問題でも？
何か問題でも？
PHPの無茶キャストっぷりを考えたら意図した通りに動くとは思えないがｗ
そもそも、それはPHPのコードなのか？
そもそも、それはPHPのコードなのか？
論争
静的および強い型付けの支持者と動的および自由な型付けの支持者の間では衝突が度々おきる。
前者のグループは厳密な型付けの使用によって、処理系がより多くのエラーを
問題が大きくなる前に発見できるようになると主張している。
後者のグループはより気軽な型付けによってコードはよりシンプルなものになり、
そのようなコードは解析しやすいとされるので、エラーは減少すると主張している。
型推論がある言語では型を手で宣言する必要はほとんどないので、強い型付けに伴う開発のオーバーヘッドは低減される。
個人がどのグループに分かれるかは、開発しているソフトウェアの種類やチームのメンバーの能力、
他のシステムとの対話性の度合い、開発チームの規模などに依ることが多い。
少人数で小回りのきくプロジェクトには気軽な型付けがより合い、フォーマルで大人数で仕事が分断されている
（プログラマ、アナリスト、テスト部隊、など）プロジェクトは厳密な型付けのほうがうまくいくことが多い、と結論づける者もいる。
静的および強い型付けの支持者と動的および自由な型付けの支持者の間では衝突が度々おきる。
前者のグループは厳密な型付けの使用によって、処理系がより多くのエラーを
問題が大きくなる前に発見できるようになると主張している。
後者のグループはより気軽な型付けによってコードはよりシンプルなものになり、
そのようなコードは解析しやすいとされるので、エラーは減少すると主張している。
型推論がある言語では型を手で宣言する必要はほとんどないので、強い型付けに伴う開発のオーバーヘッドは低減される。
個人がどのグループに分かれるかは、開発しているソフトウェアの種類やチームのメンバーの能力、
他のシステムとの対話性の度合い、開発チームの規模などに依ることが多い。
少人数で小回りのきくプロジェクトには気軽な型付けがより合い、フォーマルで大人数で仕事が分断されている
（プログラマ、アナリスト、テスト部隊、など）プロジェクトは厳密な型付けのほうがうまくいくことが多い、と結論づける者もいる。
一般に動的な型付けを持つ言語では型の特性に合わせた最適化(例えば常に浮動小数点レジスタを用いるなど)ができないので、
実行速度という面では静的型に劣ると考えられている。反面多態性や記述の容易さで動的型は融通が利き、
Smalltalkなどのオブジェクト指向言語、スクリプト言語は動的型を採用するケースが多い。
動的型と静的型のどちらが安全なプログラムを記述できるのかは長年論争の的であるが、
双方とも適した問題領域、適した開発スタイルが存在し、異なった安全観念を持つ点を理解しなければならない
通常、静的型付けはオペレーティングシステムやシステムプログラムのような大規模で厳密性が要求される領域に適合するといわれている。
反面最初の型定義を誤ると一部分の影響が全体に波及すること、また柔軟性に乏しくわずかな変換に手間のかかる経路を用意したり
同じような機能を型別に実装しなければならないことなど、いわばお役所仕事的な煩雑さを伴うという弱点を持つ。
（なお近年の研究により静的型付けの言語も文脈から型を推論する型推論能力を持つなど簡略化の方向へ向かってはいる）
一方動的型付けの言語ではそもそも対象に特定の構造を期待しないため変更への対応は柔軟である。
特に配列、辞書、集合といったコレクションの利便性が顕著で、そのため近年いわゆるスクリプト言語は多くが動的型付けを採用している。
動的型付けの難点である最適化の弱さは、コンピューターの能力が増すことで相対的に小さな問題になっており、
スクリプト言語を中心に今後も動的型付けは発展するものと思われる。
実行速度という面では静的型に劣ると考えられている。反面多態性や記述の容易さで動的型は融通が利き、
Smalltalkなどのオブジェクト指向言語、スクリプト言語は動的型を採用するケースが多い。
動的型と静的型のどちらが安全なプログラムを記述できるのかは長年論争の的であるが、
双方とも適した問題領域、適した開発スタイルが存在し、異なった安全観念を持つ点を理解しなければならない
通常、静的型付けはオペレーティングシステムやシステムプログラムのような大規模で厳密性が要求される領域に適合するといわれている。
反面最初の型定義を誤ると一部分の影響が全体に波及すること、また柔軟性に乏しくわずかな変換に手間のかかる経路を用意したり
同じような機能を型別に実装しなければならないことなど、いわばお役所仕事的な煩雑さを伴うという弱点を持つ。
（なお近年の研究により静的型付けの言語も文脈から型を推論する型推論能力を持つなど簡略化の方向へ向かってはいる）
一方動的型付けの言語ではそもそも対象に特定の構造を期待しないため変更への対応は柔軟である。
特に配列、辞書、集合といったコレクションの利便性が顕著で、そのため近年いわゆるスクリプト言語は多くが動的型付けを採用している。
動的型付けの難点である最適化の弱さは、コンピューターの能力が増すことで相対的に小さな問題になっており、
スクリプト言語を中心に今後も動的型付けは発展するものと思われる。
実行パフォーマンスには期待していない。
部分的に強い型付けが出来る程度がPHPの理想系な気がする。
部分的に強い型付けが出来る程度がPHPの理想系な気がする。
おまえらにscalaを紹介するよ
どんなに言語が簡単で優れていても、
ライブラリが揃ってない時点でPHPerは移行しないだろ。
なぜなら自前で実装する知識が無いから。
フォームデータのパースすら出来ない人がほとんどなんじゃない？
ライブラリが揃ってない時点でPHPerは移行しないだろ。
なぜなら自前で実装する知識が無いから。
フォームデータのパースすら出来ない人がほとんどなんじゃない？
つーまーりー？
仕事で使う言語を自由に選べたらこんなスレにいねーよ
まったくだな
だーけーどー？
>>377
俺は自作のフレームワークもどきを使っているよ。
最小でPHPファイル1つで完結する。
フレームワークというより、ファイルの置き方を決めた程度だけどな。
PHPを使わないでベタで書いたものから
簡単に移行できる設計になっているから、
ベタでかいていたけど、PHPファイルが数枚になって
ディレクトリ構造とか考え出したときに、すぐに変更できる。
俺は自作のフレームワークもどきを使っているよ。
最小でPHPファイル1つで完結する。
フレームワークというより、ファイルの置き方を決めた程度だけどな。
PHPを使わないでベタで書いたものから
簡単に移行できる設計になっているから、
ベタでかいていたけど、PHPファイルが数枚になって
ディレクトリ構造とか考え出したときに、すぐに変更できる。
それを今すぐ公開しろ。今すぐだ
さすがだな。スネーク
それフレームワークとは言わなくね
>>377
もう、ちいたん+pdoでええやん
もう、ちいたん+pdoでええやん
Agavi による MVC プログラミング入門
http://www.ibm.com/developerworks/jp/xml/library/x-agavipt1/?ca=drs-jp
何故か今agaviが！
http://www.ibm.com/developerworks/jp/xml/library/x-agavipt1/?ca=drs-jp
何故か今agaviが！
var_dump(strpos(100, 10));
var_dump(strpos(100, '10'));
何で結果が違ってくるの？
var_dump(strpos(100, '10'));
何で結果が違ってくるの？
>>406
マニュアル見ろよw
マニュアル見ろよw
>>407
型のことなんてどこに書いてあるの？
型のことなんてどこに書いてあるの？
>>408
ttp://jp.php.net/manual/ja/function.strpos.php
> needle が文字列でない場合は、 それを整数に変換し、
> その番号に対応する文字として扱います。
ttp://jp.php.net/manual/ja/function.strpos.php
> needle が文字列でない場合は、 それを整数に変換し、
> その番号に対応する文字として扱います。
php 5.3 で、HTML中の <?=$val> のような変数表示に関して、仕様変更ありました?
うん
php 5.3じゃなくても <?=$val> は構文エラーになると思うけど。
short_open_tag=Onにすれば、構文エラーじゃないと思ったが、
よく見たら<?=$val ?>じゃないのね。
そりゃ構文エラーだわ。
よく見たら<?=$val ?>じゃないのね。
そりゃ構文エラーだわ。
short_open_tag使わない奴はただの暇人
キー打つ時間がもったいねーだろ
キー打つ時間がもったいねーだろ
そうかそうか
>>416
いや、ユダヤだと思うよ
いや、ユダヤだと思うよ
ははっ ワロス
419 ：nobodyさん：2009/08/25(火) 13:33:43 ID:amBbmp7F
>>415
補完を知らない暇人乙
補完を知らない暇人乙
>>420
やぁ俺。だが現実的にphp4の環境で動いているところが多くて、結局自前ラッパーフレームワーク互換の
php4用自前フレームワークもどきを作って2つをメンテナンスしていく羽目になって泣いている。えーん。
やぁ俺。だが現実的にphp4の環境で動いているところが多くて、結局自前ラッパーフレームワーク互換の
php4用自前フレームワークもどきを作って2つをメンテナンスしていく羽目になって泣いている。えーん。
PHPとはちょっと関係ないんだけど、HTTP Status コードについて相談したいことがあります。
フォーム入力のバリデーションをしてエラーがあった場合、HTTP Response のステータスコードは何にすればいいでしょうか。
今までは特に指定してなかったので、結果として 200 OK を使っていたわけですが、
今度から Ajax 用のAPIを用意することになり、フォーム入力にエラーがあるかどうかを
HTTP Response のステータスコードで表すことになりました。
しかしどのステータスコードを使っていいのかよくわかりません。
フォーム入力にエラーがあることを表すにはどのステータスコードが適切でしょうか。
このスレはレベルの高い人が多いようなので、アドバイスをよろしくお願いします。
フォーム入力のバリデーションをしてエラーがあった場合、HTTP Response のステータスコードは何にすればいいでしょうか。
今までは特に指定してなかったので、結果として 200 OK を使っていたわけですが、
今度から Ajax 用のAPIを用意することになり、フォーム入力にエラーがあるかどうかを
HTTP Response のステータスコードで表すことになりました。
しかしどのステータスコードを使っていいのかよくわかりません。
フォーム入力にエラーがあることを表すにはどのステータスコードが適切でしょうか。
このスレはレベルの高い人が多いようなので、アドバイスをよろしくお願いします。
全く持ってすれ違い
そもそも用途が違う
ページリクエストに対して返すもので、コンテンツのエラーは管轄外
そもそも用途が違う
ページリクエストに対して返すもので、コンテンツのエラーは管轄外
2ch使ってる時点で終わってる
うむ
<?php を間違えて<? って書いてた。
PHP5.3に入れ替えてプログラム実行したら
ソースコードが表示されて混乱した。
PHP5.3に入れ替えてプログラム実行したら
ソースコードが表示されて混乱した。
>>423
400 Bad Requestじゃね？
400 Bad Requestじゃね？
>>433
うん。詳しくは検証していない。
php.iniで設定できるのかもしれないし、
自分がやったのがCLIだったので、CLIだけかもしれないし、
include/requireで読んでいるものは関係ないかもしれない。
が詳しくは検証していない。
考えてみれば、パスワードが含まれたファイルでミスってたら危険だね。
うん。詳しくは検証していない。
php.iniで設定できるのかもしれないし、
自分がやったのがCLIだったので、CLIだけかもしれないし、
include/requireで読んでいるものは関係ないかもしれない。
が詳しくは検証していない。
考えてみれば、パスワードが含まれたファイルでミスってたら危険だね。
素人すぎるわ
くだすれ行け
くだすれ行け
>>433-434
頭悪いとかってレベルじゃねーぞ…
そういう基本的なことすら理解してないって、よく恥ずかしげもなく宣言できるもんだなｗ
だいたいショートタグなんて使う意味がないだろ
1ファイル中に何度も書くもんでもないし、XMLとぶつかるし、こういうアホ達がやらかすし、
使わないようにしよう言われるようになってからもだいぶ久しいってのに…
頭悪いとかってレベルじゃねーぞ…
そういう基本的なことすら理解してないって、よく恥ずかしげもなく宣言できるもんだなｗ
だいたいショートタグなんて使う意味がないだろ
1ファイル中に何度も書くもんでもないし、XMLとぶつかるし、こういうアホ達がやらかすし、
使わないようにしよう言われるようになってからもだいぶ久しいってのに…
中学生乙ｗ
>>423
そもそもHTTPリクエストに対するレスポンスのステータスを示すものであって
一般的にはバリデート結果の通知に用いるような使い方はするべきでない
そういうアホなことやってる企業とかもあるにはあるし、
解釈の仕方ではそういう用途に使えると曲解できなくはないと思うけど、
悪いこと言わんからレスポンスのなかにフラグでも持たせて判断するべき
つーかスレ違いだし、まず ftp://ftp.rfc-editor.org/in-notes/rfc2068.txt 嫁
そもそもHTTPリクエストに対するレスポンスのステータスを示すものであって
一般的にはバリデート結果の通知に用いるような使い方はするべきでない
そういうアホなことやってる企業とかもあるにはあるし、
解釈の仕方ではそういう用途に使えると曲解できなくはないと思うけど、
悪いこと言わんからレスポンスのなかにフラグでも持たせて判断するべき
つーかスレ違いだし、まず ftp://ftp.rfc-editor.org/in-notes/rfc2068.txt 嫁
431、433はさすがにネタだと思いたいｗ
php使ってるやつは頭悪杉ｗよくこんなダサいの使えるな
センスを疑うよ、まったくｗｗｗ
センスを疑うよ、まったくｗｗｗ
わざわざ言いに来たお前はもっと馬鹿だということに気づいた方がいいよ
最近は文章も読めないガキが多いな。
単に、<? と ”間違って” 書いただけだろ。
俺は人生で今まで一度も間違ったことが無いってやつは
挙手しろよ。
うそつき認定してやっから（爆笑）
単に、<? と ”間違って” 書いただけだろ。
俺は人生で今まで一度も間違ったことが無いってやつは
挙手しろよ。
うそつき認定してやっから（爆笑）
キリンさんが好きです。でもショートタグはもっと好きです。
ショートタグ使う勇気もない奴は一生童貞だろうなｗ
ショートタグって悪い理由ないんだってね。
良い理由がないよ
良い理由はあるよ。キータイプの数が少ない。
ショートタグ否定する奴に限ってHTMLエスケープもろくにしてないんだから
参っちゃう
参っちゃう
XML と誤読するとか
PHPが書かれたファイルにXMLが書かれてるケースなんてほとんどないだろ
てかHTML5が出たからXMLなんてもはや下痢便以下の存在だろ
そんなもののために便利なショートタグ使わないことが許されるのは小学生まで
てかHTML5が出たからXMLなんてもはや下痢便以下の存在だろ
そんなもののために便利なショートタグ使わないことが許されるのは小学生まで
正直どうでもいい。
>PHPが書かれたファイルにXMLが書かれてるケースなんてほとんどないだろ
えっ
えっ
ブラウザの対応状況とかから言って、実際にはXML宣言なんてほとんど使わないものな。ドコモ向けにXHTMLで書くときぐらいか。
どうしてもって言うなら、JSPみたいに<%なんかに変えちゃった方が良かったと思う。数少ないPHPのメリットなのに。
どうしてもって言うなら、JSPみたいに<%なんかに変えちゃった方が良かったと思う。数少ないPHPのメリットなのに。
PHP で RSS や SOAP の動的生成とかしない子がいる
>>425
>通信自体は成功しているから200にしておくべき
えー、そうでしょうか。「通信の成功」って、どのことを指してます？
>XMLかJSONかわからないけど、status項目等を追加してシステム独自のエラーコードなりエラーメッセージで判断するのが普通と思われる。
そういう項目を追加したくないので status code を使いたいんですけどだめですか。
>>429
>通信自体は成功しているから200にしておくべき
>
>これは無いだろう
ですよねー。
>>432
>400 Bad Requestじゃね？
最初はそのつもりだったんですけど、仕様書によると、400はHTTP Requestの構文が違っていることを表すものなので、
validation errorを表すのには不適切ではないかとおもいました。（それで今回質問したわけです。）
>通信自体は成功しているから200にしておくべき
えー、そうでしょうか。「通信の成功」って、どのことを指してます？
>XMLかJSONかわからないけど、status項目等を追加してシステム独自のエラーコードなりエラーメッセージで判断するのが普通と思われる。
そういう項目を追加したくないので status code を使いたいんですけどだめですか。
>>429
>通信自体は成功しているから200にしておくべき
>
>これは無いだろう
ですよねー。
>>432
>400 Bad Requestじゃね？
最初はそのつもりだったんですけど、仕様書によると、400はHTTP Requestの構文が違っていることを表すものなので、
validation errorを表すのには不適切ではないかとおもいました。（それで今回質問したわけです。）
ショートタグがPHPのメリットとか言ってる人は、互換性やPEAR規約を知らないんだろうか。
少なくとも推奨されるべきものでは無い。
少なくとも推奨されるべきものでは無い。
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} でない場合が考えられます。
すれちがいすみませんでした。
こちらのページを参考にした結果、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} でない場合が考えられます。
すれちがいすみませんでした。
>>451
＞ PHPが書かれたファイルにXMLが書かれてるケースなんてほとんどないだろ
確かに
＞ てかHTML5が出たからXMLなんてもはや下痢便以下の存在だろ
HTML5の規格は調べてないから知らないが、どうせXML文書だろ。
XMLとXHTMLの違いも分からないのか？
＞ そんなもののために便利なショートタグ使わないことが許されるのは小学生まで
非推薦のショートタグを使うことが許されるのは素人だけ
＞ PHPが書かれたファイルにXMLが書かれてるケースなんてほとんどないだろ
確かに
＞ てかHTML5が出たからXMLなんてもはや下痢便以下の存在だろ
HTML5の規格は調べてないから知らないが、どうせXML文書だろ。
XMLとXHTMLの違いも分からないのか？
＞ そんなもののために便利なショートタグ使わないことが許されるのは小学生まで
非推薦のショートタグを使うことが許されるのは素人だけ
XML宣言は必須じゃないしね。
ショートタグの何を恐れているのか
理解できない。
ショートタグの何を恐れているのか
理解できない。
>>456,458
それも違うと思うが
それも違うと思うが
PHPってバージョン4になってから以降、開発者のセンス悪すぎ。ショートタグを止めたと思ったら、gotoを導入するとか。
>>460
未対応設定になってるサーバがあったり、
顧客の社内規約で禁止になってたりするからじゃない？
個人的にはオープンソースなスクリプトでショートタグ使ってたら、一気に醒める。
利便性より汎用性。
未対応設定になってるサーバがあったり、
顧客の社内規約で禁止になってたりするからじゃない？
個人的にはオープンソースなスクリプトでショートタグ使ってたら、一気に醒める。
利便性より汎用性。
>>462
それ以前からどうしようもないセンスだったと思うが。
それ以前からどうしようもないセンスだったと思うが。
>>462
finally 実装しないでgotoだもんな。
しかも try/catchより goto の方がコードが綺麗になるとか言っちゃうくらいだし･･･
PHPユーザの質の低さがばればれだよね。
(ネームスペースもgotoもユーザ意見で最終決定したと思われる)
ここもいずれ、goto厨が湧いて「便利なのになんで使わないんだ！」とか言い出すんだろうね。
finally 実装しないでgotoだもんな。
しかも try/catchより goto の方がコードが綺麗になるとか言っちゃうくらいだし･･･
PHPユーザの質の低さがばればれだよね。
(ネームスペースもgotoもユーザ意見で最終決定したと思われる)
ここもいずれ、goto厨が湧いて「便利なのになんで使わないんだ！」とか言い出すんだろうね。
<?php
goto hell
hell: die('＼(^o^)／ｵﾜﾀ');
goto hell
hell: die('＼(^o^)／ｵﾜﾀ');
すごく…自演くさいです…
?>を書く必要があるような書き方をしたくないのでショートタグなんて絶対使いません
ショートタグ使わん人はView Templateはどう書いてるの？それともSmarty？
Smarty
ショートタグ否定派はスマーティー派かｗ
通りで・・
通りで・・
スマーティー（(笑)）
主にコード書く側の人間で率先してショートタグ使おうなんて人はいないだろう
VIEW専門の無知な奴がよく理解もしてないのにショートタグ使って俺玄人だぜ気分に浸って
>>431,433みたいな事とやらかしてしまうんじゃろうて
VIEW専門の無知な奴がよく理解もしてないのにショートタグ使って俺玄人だぜ気分に浸って
>>431,433みたいな事とやらかしてしまうんじゃろうて
ショートタグに違和感憶えない奴はどう考えてもプログラマには向いていない。
>>421
<?=[ENTER] で <?php echo | ?> とか
<?=h[ENTER] で <?php echo htmlspecialchars(|) ?> (パイプがキャレット位置)とか
したらいいじゃん。
<?=[ENTER] で <?php echo | ?> とか
<?=h[ENTER] で <?php echo htmlspecialchars(|) ?> (パイプがキャレット位置)とか
したらいいじゃん。
View TemplateにPHP使ったことない。コメントとかどうやって書くの?
Yahoo!とかGooのサービスのHTMLソース見るとHTMLのコメントだらけ。
Yahoo!とかGooのサービスのHTMLソース見るとHTMLのコメントだらけ。
えっ
なんとｗ
<?php echo コメント > /dev/null ?>
かな?
かな?
ここ本当にフレームワークのスレかよｗｗ
Smarty厨は隔離スレに帰れｗｗｗ
Smarty厨は隔離スレに帰れｗｗｗ
ミスリードする人間に反応しすぎじゃないかな。
こうやってスレ違いに厳しくなってしまうんだけど、しょうがない部分もあるよね。
こうやってスレ違いに厳しくなってしまうんだけど、しょうがない部分もあるよね。
ショートタグ自体は別に悪では無いが、
非対応環境があるから、フレームワークを作る上では敬遠されている。
バージョンアップや設定ミスで、ショートタグが動かなくなった場合のリスクを考えると、あまり賢い選択では無い気がする。
非対応環境があるから、フレームワークを作る上では敬遠されている。
バージョンアップや設定ミスで、ショートタグが動かなくなった場合のリスクを考えると、あまり賢い選択では無い気がする。
どっちでもいいなそんな事
ソースコード公開するなら関係するよな
でもここはフレームワークについて語るスレ13
＿_
, ‐' ´ ｀`‐、 ／￣:三}
. ／,. -─‐- ､. ヽ / ,.＝j
＿,.:_'＿＿＿＿＿_ヽ、 .! .／ _,ﾉ
`‐、{ へ 'ﾞ⌒ `!~ヽ. ! ／{. /
｀! しﾟ （ ﾟj `v‐冫 , '::::::::ヽ､/ そんなことよりフレームワークの話しようぜ！
. {.l '⌒ ﾞ 6',! / :::::::::::::::/ __
. 〈 < ´￣,ﾌ .ﾉｰ'_ , ‐'´::::::::::::::;/ （_ノ)‐-､
. ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠. ヽ_} ﾞヽ
,.r｀ "´ ／:::::::::::::::::::ィ´ ｀ゝ !、 /
/ / :::::::::::::::: ; '´ /´＼ / r'＼
. i ! ::::::::::::::／ 墨 | .!::::::::／ヽ､.._!ヽ. ヽ､
{ {:::::::::::;:ｲ / ‖ｉ:::::::/:::::::::::::/ ＼
. ヽ ヽ,.ｧ‐'´ /ヽ 二 ,/`ヽ、::::::::: ／
でもここはフレームワークについて語るスレ13
＿_
, ‐' ´ ｀`‐、 ／￣:三}
. ／,. -─‐- ､. ヽ / ,.＝j
＿,.:_'＿＿＿＿＿_ヽ、 .! .／ _,ﾉ
`‐、{ へ 'ﾞ⌒ `!~ヽ. ! ／{. /
｀! しﾟ （ ﾟj `v‐冫 , '::::::::ヽ､/ そんなことよりフレームワークの話しようぜ！
. {.l '⌒ ﾞ 6',! / :::::::::::::::/ __
. 〈 < ´￣,ﾌ .ﾉｰ'_ , ‐'´::::::::::::::;/ （_ノ)‐-､
. ヽ.、 ` ‐", ‐´‐:ラ ':::::::::::::::: ;∠. ヽ_} ﾞヽ
,.r｀ "´ ／:::::::::::::::::::ィ´ ｀ゝ !、 /
/ / :::::::::::::::: ; '´ /´＼ / r'＼
. i ! ::::::::::::::／ 墨 | .!::::::::／ヽ､.._!ヽ. ヽ､
{ {:::::::::::;:ｲ / ‖ｉ:::::::/:::::::::::::/ ＼
. ヽ ヽ,.ｧ‐'´ /ヽ 二 ,/`ヽ、::::::::: ／
最悪、テンプレートファイルをgrepやsedで一括置換すれば何とかなる。
とりあえずZend最高
んじゃ、Zendを活用したCakePHP最高
他の言語に移行したいけどCakePHPでサイト作るのに慣れすぎて移行できないよ＼(^o^)／
cakeってちょっと見たけど
1テーブル1コントローラがキモすぎて吐いたわ
どんな顔してあんなの使ってるのか見てみたいものだね
1テーブル1コントローラがキモすぎて吐いたわ
どんな顔してあんなの使ってるのか見てみたいものだね
具体的に1テーブル1コントローラの何がきもいと感じてるの？
柔軟性がなさそうできもいとかそういう感じ？
柔軟性がなさそうできもいとかそういう感じ？
コントローラとモデルがくっついてる意味が分からないです・・
コントローラはコントローラ、モデルはモデルだろ・・
コントローラはコントローラ、モデルはモデルだろ・・
なるほど。
くっついてると言うよりは単に名前を同じようにすることを推奨してる感じかな。
規約上では例えばuserモデルにはusers_controllerを対応させるように、って仕向けてるけど、
そのくっつき感が嫌ならhogefuga_controllerでuserモデルを使用するってこともできる。
なんかうまく書けないな…ごめんなさい
くっついてると言うよりは単に名前を同じようにすることを推奨してる感じかな。
規約上では例えばuserモデルにはusers_controllerを対応させるように、って仕向けてるけど、
そのくっつき感が嫌ならhogefuga_controllerでuserモデルを使用するってこともできる。
なんかうまく書けないな…ごめんなさい
まあなんというか492がcakeを使いこなせてないのは確実。
Cakeが、
DB table <-> Model <-> Controller が全て１対１対応になっている
（ように見える）はデフォルトの規約のせい。
実際はどうにでもできるし、また習熟すればModel中心で
開発できるようにもなる。
DB table <-> Model <-> Controller が全て１対１対応になっている
（ように見える）はデフォルトの規約のせい。
実際はどうにでもできるし、また習熟すればModel中心で
開発できるようにもなる。
最近のフレームワークは肥大化しすぎてて、
PHPの学習コストの低さを完全に打ち消しちゃってるよね。
進化も早いから新人教育が本当に面倒くさい･･･。
PHPの学習コストの低さを完全に打ち消しちゃってるよね。
進化も早いから新人教育が本当に面倒くさい･･･。
そうなの？
工数減らす事より、コーディング品質を上げる為に導入って会社の方が多い気がするけど・・・
規模が大きければ大きいほど、工数の大半はビジネスロジックになるから
フレームワークで減らせる工数なんてたかが知れてない？
逆に無謀なカスタマイズを要求されて、時間と技術を無駄にしている気すらある。
工数減らす事より、コーディング品質を上げる為に導入って会社の方が多い気がするけど・・・
規模が大きければ大きいほど、工数の大半はビジネスロジックになるから
フレームワークで減らせる工数なんてたかが知れてない？
逆に無謀なカスタマイズを要求されて、時間と技術を無駄にしている気すらある。
フレームワークってのはぶっちゃけテンプレートの集合であって
中身と使い方を理解しなければ使い物にならないんだぞ
中身と使い方を理解しなければ使い物にならないんだぞ
よくsymfonyの説明で「このフレームワークは大規模案件にも対応できる！」って書かれてるけど、
具体的にどの辺りが大規模向けなの？コントローラとかのディレクトリが階層状態になってるから
ファイルが多くなっても大丈夫、とかだけじゃないよね？
具体的にどの辺りが大規模向けなの？コントローラとかのディレクトリが階層状態になってるから
ファイルが多くなっても大丈夫、とかだけじゃないよね？
>>496
というかFW無しで、それなりの規模でしっかりしたWEBアプリ作れるように新人教育する方が確実に大変だろ・・
>>492
きちんと使ってもいないのに語るのはやめた方がいいよ。
MVCきっちり分かれてるし、自由に切り替え可能。
モデル使わないコントローラーだって当然可能だし。
というかFW無しで、それなりの規模でしっかりしたWEBアプリ作れるように新人教育する方が確実に大変だろ・・
>>492
きちんと使ってもいないのに語るのはやめた方がいいよ。
MVCきっちり分かれてるし、自由に切り替え可能。
モデル使わないコントローラーだって当然可能だし。
>>500
規約がかっちりしてるからパラレルに作業しやすいとかかな
規約がかっちりしてるからパラレルに作業しやすいとかかな
>>504
名前じゃなくて中身が本質なんだと思うがｗ
命名規則とかタブ幅とかが書かれたコーディング規約だけじゃなくて、
CoC的な意味での設定とか規約とかも含めた、構造そのものが範囲じゃないかな。
すげーざっくり言うと「コードを書く場所を機能別に分ける」ってことだよ。
ファイルを階層別に分けるのも、命名規則をつけるのも、その目的を果たすためにしたことだ。
個人的には、symfonyが大規模案件に向いているというのはすごく眉唾で、
「PHPの実績あるフレームワークで大規模案件をやるならsymfonyしか選択肢がない」
というのが日本の実情に近いんだと思う。
名前じゃなくて中身が本質なんだと思うがｗ
命名規則とかタブ幅とかが書かれたコーディング規約だけじゃなくて、
CoC的な意味での設定とか規約とかも含めた、構造そのものが範囲じゃないかな。
すげーざっくり言うと「コードを書く場所を機能別に分ける」ってことだよ。
ファイルを階層別に分けるのも、命名規則をつけるのも、その目的を果たすためにしたことだ。
個人的には、symfonyが大規模案件に向いているというのはすごく眉唾で、
「PHPの実績あるフレームワークで大規模案件をやるならsymfonyしか選択肢がない」
というのが日本の実情に近いんだと思う。
それだけ聞くと別にsymfonyじゃなくても良いと思えてしまう。
勿論、設計がしっかりしてりゃなんだっていいし、別にオレオレフレームワーク作ったって構わないわな
「設計がしっかりしてる」ってのをどこで判断するんだ、って話だ
symfonyに限らず、実際にそのフレームワークで構築された大規模サイトがある、ってのは、大規模な案件になっても設計的に破綻しないという何よりの証明
採用件数が多ければ、トラブルシュートの類も蓄積されてるだろうしな
ユーザー数が多いという事は、本体の開発者も多い事が期待できるし
「設計がしっかりしてる」ってのをどこで判断するんだ、って話だ
symfonyに限らず、実際にそのフレームワークで構築された大規模サイトがある、ってのは、大規模な案件になっても設計的に破綻しないという何よりの証明
採用件数が多ければ、トラブルシュートの類も蓄積されてるだろうしな
ユーザー数が多いという事は、本体の開発者も多い事が期待できるし
日本においてはその限りでは無い気が･･･
509 ：名無しさん＠そうだ選挙に行こう：2009/08/30(日) 04:05:27 ID:???
うーんぶっちゃけ、そんなに「開発規模が大きくなる事」とか、
「開発規模が大きくなることを念頭に置かれた設計である事」に魅力を感じるか？
と自分に問うと、自分の場合はそうは思わん。（仕事の面白さ的にも）
ただ「運用していくうえでのスケーラビリティだけは確保しときたいよね」って所と、
コードの見通しの確保、あと万一ソースコードを他者に引き継ぐとかって話になった時に
話が少しだけ早くなる、っていう3点だな。
自分がPHP案件でオープンなアプリケーションフレームワークを利用する意味は、そのくらいだと思う。
まあ、自分みたいなタイプは少ないかもしれん。
もしかしたら結構みんな、多数の人員で多くの人月かける仕事が好きなのかもしれないし。
「開発規模が大きくなることを念頭に置かれた設計である事」に魅力を感じるか？
と自分に問うと、自分の場合はそうは思わん。（仕事の面白さ的にも）
ただ「運用していくうえでのスケーラビリティだけは確保しときたいよね」って所と、
コードの見通しの確保、あと万一ソースコードを他者に引き継ぐとかって話になった時に
話が少しだけ早くなる、っていう3点だな。
自分がPHP案件でオープンなアプリケーションフレームワークを利用する意味は、そのくらいだと思う。
まあ、自分みたいなタイプは少ないかもしれん。
もしかしたら結構みんな、多数の人員で多くの人月かける仕事が好きなのかもしれないし。
510 ：名無しさん＠そうだ選挙に行こう：2009/08/30(日) 15:50:15 ID:???
>>509
俺は大規模案件に魅力を感じる。
みんな知ってるあのサイト、実は俺俺フレームワークで動いてるんだぜ、
とか言ってみたいものだわ。そういうのに挑戦していきたい。
「Railsもどきを作りましょう」じゃなくて「案件ありき」で作った。
俺がsymfonyをリスペクトしてる理由は、それだけだな。
フレームワークとしてはちっとも高性能でも万能でも無いと思うが、
大規模案件のお手本にするには十分ためになるよ。
あと、微妙に「大規模」の定義がずれてるような気もするｗ
俺は大規模案件に魅力を感じる。
みんな知ってるあのサイト、実は俺俺フレームワークで動いてるんだぜ、
とか言ってみたいものだわ。そういうのに挑戦していきたい。
「Railsもどきを作りましょう」じゃなくて「案件ありき」で作った。
俺がsymfonyをリスペクトしてる理由は、それだけだな。
フレームワークとしてはちっとも高性能でも万能でも無いと思うが、
大規模案件のお手本にするには十分ためになるよ。
あと、微妙に「大規模」の定義がずれてるような気もするｗ
511 ：名無しさん＠そうだ選挙に行こう：2009/08/30(日) 16:08:56 ID:???
アクセス規模が大きい、って意味の大規模だと、symfonyやcakeは微妙だな
最終的には素のPHPで必要最小限の処理を手続き的に書くのが最速になる
この場合の「大規模」は、機能数や、エンジニア数（工数）という意味での「大規模」だと思う
最終的には素のPHPで必要最小限の処理を手続き的に書くのが最速になる
この場合の「大規模」は、機能数や、エンジニア数（工数）という意味での「大規模」だと思う
512 ：名無しさん＠そうだ選挙に行こう：2009/08/30(日) 16:26:32 ID:???
規模がでかいんだったら俺ならJavaにするな
513 ：名無しさん＠そうだ選挙に行こう：2009/08/30(日) 16:46:32 ID:???
規模がでかいんだったら俺ならYiiにするな
514 ：名無しさん＠そうだ選挙に行こう：2009/08/30(日) 17:02:32 ID:???
yii使ってる人いるの？
個人的に使い始めてる人はいると思うよ
いろいろ便利
いろいろ便利
Javaって共有レンタルサーバーで使えるようになるかな？
もちろん探せば使えるところあるだろうけど、
PHPぐらいにたいてい対応しているレベルになるかなってこと。
もちろん探せば使えるところあるだろうけど、
PHPぐらいにたいてい対応しているレベルになるかなってこと。
スレ違い
>>517
うるさい
うるさい
スレ違い
共有鯖で大規模サイトやりたいのか？ｗｗｗ
スレ違いと言ったらうるさいと言われた。ワロタ
>>510
>>511
確かに「工数としての大規模」と「アクセスが大規模」の話がこんがらがってるね。
自分が言いたかったのは、前者の意味での大規模に、それほどの面白みを（個人的には）感じないという事。
でも、当然アクセス規模が（意図する・しないにかかわらず）大きくなるような案件には夢を感じる。
そういう時に、後からスケールアウトしやすく設計されているフレームワークを使っておくのはひとつの手だと思う。
最初からDBレプリケーションだのmemcacheだの利用した実装してアクセス全然だったらアチャーって思っちまうし。
話のポイント外してるようだったらごめん
>>511
確かに「工数としての大規模」と「アクセスが大規模」の話がこんがらがってるね。
自分が言いたかったのは、前者の意味での大規模に、それほどの面白みを（個人的には）感じないという事。
でも、当然アクセス規模が（意図する・しないにかかわらず）大きくなるような案件には夢を感じる。
そういう時に、後からスケールアウトしやすく設計されているフレームワークを使っておくのはひとつの手だと思う。
最初からDBレプリケーションだのmemcacheだの利用した実装してアクセス全然だったらアチャーって思っちまうし。
話のポイント外してるようだったらごめん
個人的にはZendみたいなライブラリ集っぽいモノに、
俺俺フレームワークをかぶせるのがベストプラクティスだと思っている。
DBとかセッションとか普遍的なロジックはライブラリ集を使って、
認証やバリデーション、コントローラ/モデルあたりの毎回ロジックに改修が入る部分は、
自分の使いやすい方式で実装するのが良いと思う。
質問スレとかで、自分で書けば数行のものを、むりくりフレームワークを改修して実現しようとしている人を見ると微妙な気持ちになるわ。
俺俺フレームワークをかぶせるのがベストプラクティスだと思っている。
DBとかセッションとか普遍的なロジックはライブラリ集を使って、
認証やバリデーション、コントローラ/モデルあたりの毎回ロジックに改修が入る部分は、
自分の使いやすい方式で実装するのが良いと思う。
質問スレとかで、自分で書けば数行のものを、むりくりフレームワークを改修して実現しようとしている人を見ると微妙な気持ちになるわ。
自分ひとりでやるならオレオレでもいいだろう。
けど他人が絡むのであれば、それではまずいだろう。
けど他人が絡むのであれば、それではまずいだろう。
>>525
個々がフリーダムにコーディングしてしまうとまずいだろうが、
ある程度の規定を決めて社内フレームワーク的なモノにすればよくね？
仮に特定のフレームワークを導入したとしても、連携とれるかどうかは別だしさ。
むしろ既存フレームワークを誰かがカスタマイズしてしまうと、余計にカオスな状況になる気がする。
個々がフリーダムにコーディングしてしまうとまずいだろうが、
ある程度の規定を決めて社内フレームワーク的なモノにすればよくね？
仮に特定のフレームワークを導入したとしても、連携とれるかどうかは別だしさ。
むしろ既存フレームワークを誰かがカスタマイズしてしまうと、余計にカオスな状況になる気がする。
設定ファイルで全て賄おうとする思想のフレームワークが嫌いだ。
大抵、設定ファイルという名の新言語になっている。
大抵、設定ファイルという名の新言語になっている。
> 個々がフリーダムにコーディングしてしまうとまずいだろうが、
> ある程度の規定を決めて社内フレームワーク的なモノにすればよくね？
であれば既存のフレームワークでいいのでは？
なぜ、車輪を再発明してまでFWを自作したい？
よっぽど特殊なドメインのWebシステムで無い限りはそんな必要性ないかと。
> ある程度の規定を決めて社内フレームワーク的なモノにすればよくね？
であれば既存のフレームワークでいいのでは？
なぜ、車輪を再発明してまでFWを自作したい？
よっぽど特殊なドメインのWebシステムで無い限りはそんな必要性ないかと。
ようするにエンジニアだから。
全部自分で作ってみたいんだよ。
フレームワークみたいなブラックボックスが我慢できないんだよ。
全部自分で作ってみたいんだよ。
フレームワークみたいなブラックボックスが我慢できないんだよ。
Cよりアセンブラと思ってた時期もあったな
FWのソースを見て理解出来ないようなヤツは、
ハナから黙ってそれを使え。
ハナから黙ってそれを使え。
>>526
結果的に使う人にとっては、同じようなFWになる気がするけど
自社だろうが、既存フレーワークだろうが使用するだけの人にとっては今まで出てきたような問題のメリットもある。
すでに十分な機能の自社フレームワークがあるならいいけど、既存のFWより機能の少ないものを作ってそんなにメリットあるのかな。
速度?でも色々付けたらそんな変わらないんじゃないの?
結果的に使う人にとっては、同じようなFWになる気がするけど
自社だろうが、既存フレーワークだろうが使用するだけの人にとっては今まで出てきたような問題のメリットもある。
すでに十分な機能の自社フレームワークがあるならいいけど、既存のFWより機能の少ないものを作ってそんなにメリットあるのかな。
速度?でも色々付けたらそんな変わらないんじゃないの?
>>529
>であれば既存のフレームワークでいいのでは？
おまえさ、もうちょっと話の流れを追ってから書き込もうぜ。
526だけじゃなくて、もうちょっと上の523あたりから読んでみなよ。
既存のフレームワークに問題点を感じているから話がはじまったのに、
「既存のフレームワークでいいのでは？」とはこれいかに。
>であれば既存のフレームワークでいいのでは？
おまえさ、もうちょっと話の流れを追ってから書き込もうぜ。
526だけじゃなくて、もうちょっと上の523あたりから読んでみなよ。
既存のフレームワークに問題点を感じているから話がはじまったのに、
「既存のフレームワークでいいのでは？」とはこれいかに。
> フレームワークを使っても、毎回どっか改造しなきゃいけないところがあって、
っていうか俺今までいろんなフレームワーク使ってきたことがあるが、
フレームワーク自体に手を入れなきゃいけなかったことなんて一度もないんだが。
単に、フレームワークを使いこなせていないだけなのでは？
っていうか俺今までいろんなフレームワーク使ってきたことがあるが、
フレームワーク自体に手を入れなきゃいけなかったことなんて一度もないんだが。
単に、フレームワークを使いこなせていないだけなのでは？
FWの設計的に想定外の処理を追加したい場合とかに
大げさなラッパーコードを書かなきゃいけないのが不毛だって話だよね。
てゆーかどんなフレームワーク使ってても、
自然とそれを覆う為の俺俺フレームワーク(クラス群)が出来上がらないか？
>>536
フレームワーク自体は書き換えないだろ･･･
それを覆うコード群が膨大になると結局カオスになる。って事かと。
大げさなラッパーコードを書かなきゃいけないのが不毛だって話だよね。
てゆーかどんなフレームワーク使ってても、
自然とそれを覆う為の俺俺フレームワーク(クラス群)が出来上がらないか？
>>536
フレームワーク自体は書き換えないだろ･･･
それを覆うコード群が膨大になると結局カオスになる。って事かと。
>>529
>>533
全てを再発明するわけでは無いよ。
既存フレームワークの設計上、実装が面倒になりそうな部分は、自前で書く方がメリットあるんじゃない？
既存フレームワーク ＋ 自作の使いやすいコンポーネント ＝ 俺俺フレームワーク
>>533
全てを再発明するわけでは無いよ。
既存フレームワークの設計上、実装が面倒になりそうな部分は、自前で書く方がメリットあるんじゃない？
既存フレームワーク ＋ 自作の使いやすいコンポーネント ＝ 俺俺フレームワーク
きちんとしたFWでそこまで大きな改修やラッパーが必要になるかな・・
っていうのは同意
特殊なものを作ってるのかもしれないが
っていうのは同意
特殊なものを作ってるのかもしれないが
ZendFramework使ってるけど、コアな処理にZend系クラスを直で使ってしまうと後々カスタマイズが出来ないので、
継承クラスや、ラッパーを作って使っている。
普通はするよ・・・ね？
継承クラスや、ラッパーを作って使っている。
普通はするよ・・・ね？
そもそもZFは使ってないけど、他FWのライブラリとして使ってるという印象。
こういう種類があるということか。
1. FWなし
2. 100%俺俺FW
3. 100%一般的なFW
4. 一般的なFWの上に、俺俺FW
俺の場合、新しいプロジェクトを作るときは、たいていそれまでに作った
似たようなプロジェクトのコードをテンプレート代わりに使ったりするから、
上の分類だと4ということになるのか？
1. FWなし
2. 100%俺俺FW
3. 100%一般的なFW
4. 一般的なFWの上に、俺俺FW
俺の場合、新しいプロジェクトを作るときは、たいていそれまでに作った
似たようなプロジェクトのコードをテンプレート代わりに使ったりするから、
上の分類だと4ということになるのか？
>>542
正直1と2はスレ違いな気もするw
正直1と2はスレ違いな気もするw
実際に使うのは下っ端ですから・・・
>>544
自分の場合はZFの不具合(日本語系)に悩まされて、パッチとしてラッパー作るようになったｗ
自分の場合はZFの不具合(日本語系)に悩まされて、パッチとしてラッパー作るようになったｗ
>>546みたいに問題が起きたり問題が起きそうなクラスだけ
ラップするのは普通だし現実的だと思う
>>540が何でもかんでもとにかくラップするっていう話なら
ちょっと無駄な気はする。まあ、何でもかんでもってことは
さすがにないか
ラップするのは普通だし現実的だと思う
>>540が何でもかんでもとにかくラップするっていう話なら
ちょっと無駄な気はする。まあ、何でもかんでもってことは
さすがにないか
既存のシステムからのコールを、極力回収や学習をしなくてもいい形にZFにつなぐためのラッパーならも
ありかなと個人的に思う。
学習についてはいろいろあるだろうけど、今まで作ってて結局周りを巻き込んで学習する時間なかったり
するもんで、php4とかで使用してたライブラリのコール仕様になるべく併せた形に書き換えて作ったことは何度かあった。
ありかなと個人的に思う。
学習についてはいろいろあるだろうけど、今まで作ってて結局周りを巻き込んで学習する時間なかったり
するもんで、php4とかで使用してたライブラリのコール仕様になるべく併せた形に書き換えて作ったことは何度かあった。
>>522
> 後からスケールアウトしやすく設計されているフレームワーク
実際、無いよなあｗ
だから、俺俺フレームワークでラップしてるような気がする。
開発者や開発案件の思想に依存する「俺俺スケール」が先にあるのかも知れない。
やってる事がbug-fixにとどまらず、俺俺部分に意志が入っちゃうんだよね。
>>542の分類で言うなら、
「一般的なFWの上に、俺俺bug-fixを加えただけのもの」
があってもいいはずなのに、なかなかそれだけで改造が終わることが無いｗ
> 後からスケールアウトしやすく設計されているフレームワーク
実際、無いよなあｗ
だから、俺俺フレームワークでラップしてるような気がする。
開発者や開発案件の思想に依存する「俺俺スケール」が先にあるのかも知れない。
やってる事がbug-fixにとどまらず、俺俺部分に意志が入っちゃうんだよね。
>>542の分類で言うなら、
「一般的なFWの上に、俺俺bug-fixを加えただけのもの」
があってもいいはずなのに、なかなかそれだけで改造が終わることが無いｗ
インスタンス生成部だけ独自実装して素のZend使えばいいんじゃね。
差し迫った必要に迫られても、同じインターフェイスを持つ別のクラスを返すようにすればサクっと入れ替えられるしな。
まあ、DIなわけだが。
俺の場合、PDOのラッパークラスはかなり頻繁に作るな。フレームワークじゃなくて言語組み込みだからちとアレだが。
全メソッド呼び出しを記録できると色々便利。
差し迫った必要に迫られても、同じインターフェイスを持つ別のクラスを返すようにすればサクっと入れ替えられるしな。
まあ、DIなわけだが。
俺の場合、PDOのラッパークラスはかなり頻繁に作るな。フレームワークじゃなくて言語組み込みだからちとアレだが。
全メソッド呼び出しを記録できると色々便利。
DIでいいじゃん
>>552
はいはい僕ちゃんは使いこなせてて凄いでしゅねー
はいはい僕ちゃんは使いこなせてて凄いでしゅねー
おまいら仕事しろよ
>>549
レスありがとう
自分自身の感覚になってしまうけど、
CakeにしろSymfonyにしろ（この２つしか例に出せないゴメン）、
十分にスケールアウトを考慮した設計になってると思うよ。
でも逆に言えば、サーバ一台で完結させるような場合には、どうしてもオーバーヘッドが出て来るよね
むしろ本当に書き捨てでいいアプリならば、これらを使わずに
「俺俺」や「素のPHP」でもいいと思う。というかむしろそうする。
レスありがとう
自分自身の感覚になってしまうけど、
CakeにしろSymfonyにしろ（この２つしか例に出せないゴメン）、
十分にスケールアウトを考慮した設計になってると思うよ。
でも逆に言えば、サーバ一台で完結させるような場合には、どうしてもオーバーヘッドが出て来るよね
むしろ本当に書き捨てでいいアプリならば、これらを使わずに
「俺俺」や「素のPHP」でもいいと思う。というかむしろそうする。
>>555
ん？
俺は>>522読んで、（アクセス規模に対する）スケールアウトという言葉の用例が、
DBレプリケーションやmemcacheにかかってるんだと思ってた。
>>556
アクセス規模が増えてDBレプリケーションやmemcacheを使いたくなった時に、
Cakeやsymfonyだと簡単に移行できるかどうかって話だよね？
>>511と同じく、個人的にはそうは思えなかったけど、改めて調べてみると、
CakeではDBレプリケーション対応は簡単みたいだね。Propel13はダメだ（反論求む）
それに後付けのmemcache対応はどっちでも難しい。（反論求む）
sfSuperCacheも後付けで使うには設計を直す必要があるし（反論求む）
URIの変更もsfRouteやroutesだけの設定じゃ厳しい（ずれてる？）
ん？
俺は>>522読んで、（アクセス規模に対する）スケールアウトという言葉の用例が、
DBレプリケーションやmemcacheにかかってるんだと思ってた。
>>556
アクセス規模が増えてDBレプリケーションやmemcacheを使いたくなった時に、
Cakeやsymfonyだと簡単に移行できるかどうかって話だよね？
>>511と同じく、個人的にはそうは思えなかったけど、改めて調べてみると、
CakeではDBレプリケーション対応は簡単みたいだね。Propel13はダメだ（反論求む）
それに後付けのmemcache対応はどっちでも難しい。（反論求む）
sfSuperCacheも後付けで使うには設計を直す必要があるし（反論求む）
URIの変更もsfRouteやroutesだけの設定じゃ厳しい（ずれてる？）
PHP最高（反論求む）
ZFは他のFWに比べると書くコード量が一回り増えるけどなｗ
memcacheなんてもともとシンプルなんだから自分でクラス書けばすぐじゃん
dbの分散化対応は面倒くさいけど
dbの分散化対応は面倒くさいけど
memcacheってほんの数行のサンプルコードしかみてないんだけど
たんに良くあるキャッシュコードでファイルに保存する代わりに
メモリに保存してるだけだろ？
たんに良くあるキャッシュコードでファイルに保存する代わりに
メモリに保存してるだけだろ？
PHPってやっぱりドイツの普及率が一番低いのかな？
ドイツ発のフレームワークってないし
ドイツ発のフレームワークってないし
イギリス発とかフランス発とかのフレームワークなんてあるのかい？
フレームワークは全部韓国発ですよ？
symfonyはフランス発だよ
ドイツ発PHPフレームワーク誕生！その名もadolf
>>559
kwsk
>>562
DBレプリケーションも、それ前提で自作すりゃ簡単だろうさ。
memcacheもそうで、key-value型のホルダを先に作っておけば移行は容易。
でもmemcacheでやりたい事がテーブルやクエリ結果のキャッシュだったら、
それはフレームワーク備え付けのDBアクセス手段じゃ実現困難だよねって話。
kwsk
>>562
DBレプリケーションも、それ前提で自作すりゃ簡単だろうさ。
memcacheもそうで、key-value型のホルダを先に作っておけば移行は容易。
でもmemcacheでやりたい事がテーブルやクエリ結果のキャッシュだったら、
それはフレームワーク備え付けのDBアクセス手段じゃ実現困難だよねって話。
570 ：nobodyさん：2009/09/05(土) 05:37:36 ID:HKGmqHHH
CakePHPでSQLite3ドライバ使って、
日記サイトみたいなの作ってるんだけど
なんかJOINの結果が変。
他のDBに切り替えようと探してたらPosqlていうドライバ見つけた。
これけっこうｲｲｶﾓ。
SQLダンプからインポートして今のとこ順調。
日記サイトみたいなの作ってるんだけど
なんかJOINの結果が変。
他のDBに切り替えようと探してたらPosqlていうドライバ見つけた。
これけっこうｲｲｶﾓ。
SQLダンプからインポートして今のとこ順調。
>>569
>でもmemcacheでやりたい事がテーブルやクエリ結果のキャッシュだったら、
>それはフレームワーク備え付けのDBアクセス手段じゃ実現困難だよねって話。
>>562は、この点↑を含めて、既存のDBアクセス周りをラップする
クラスを作ればいいんじゃね？って言ってるんだと思うぞ
それに何でもかんでもmemcache頼みってのもどうかと思うぞ
DB周りのメモリチューニングとか、あるいはオンメモリDBを使うとか
その辺は検討したのか？
>でもmemcacheでやりたい事がテーブルやクエリ結果のキャッシュだったら、
>それはフレームワーク備え付けのDBアクセス手段じゃ実現困難だよねって話。
>>562は、この点↑を含めて、既存のDBアクセス周りをラップする
クラスを作ればいいんじゃね？って言ってるんだと思うぞ
それに何でもかんでもmemcache頼みってのもどうかと思うぞ
DB周りのメモリチューニングとか、あるいはオンメモリDBを使うとか
その辺は検討したのか？
>>571
> それに何でもかんでもmemcache頼みってのもどうかと思うぞ
ごめん、memcacheの話は自分が最初に振っちゃったので、
>>549 (>>569)関係ない。
自分は>>549 (>>557) 読んで、まあ確かに、config書き換えですぐに対応出来る訳ではないよなーと
思った。
> それに何でもかんでもmemcache頼みってのもどうかと思うぞ
ごめん、memcacheの話は自分が最初に振っちゃったので、
>>549 (>>569)関係ない。
自分は>>549 (>>557) 読んで、まあ確かに、config書き換えですぐに対応出来る訳ではないよなーと
思った。
もうそろそろkey-value方式の
フレームワークが出ても良いと思うんだ。
フレームワークが出ても良いと思うんだ。
>>573
普通にCakePHPは対応してるでしょ
普通にCakePHPは対応してるでしょ
違うか普通にキャッシュとして対応してるのか
>>575
そういうこと。
キャッシュではなくモデルがkey-valueを基礎としているフレームワーク
O/Rつかってリレーショナルなデータをオブジェクトに変換するより
楽じゃないかと思うけどな。
ストレージとして、barkleyDBのようなkey-valueなデータベースだけじゃなく
ファイルやRDBにも格納できる設計で。
そういうこと。
キャッシュではなくモデルがkey-valueを基礎としているフレームワーク
O/Rつかってリレーショナルなデータをオブジェクトに変換するより
楽じゃないかと思うけどな。
ストレージとして、barkleyDBのようなkey-valueなデータベースだけじゃなく
ファイルやRDBにも格納できる設計で。
>>571
> 既存のDBアクセス周りをラップするクラスを作ればいいんじゃね？
DBの結果セットをmemcachedに移行するというアプローチは、
自分でやった時はうまくいかなかったなあ。
結局、ご指摘の通りにオンメモリにして逃げちゃった。
なので、簡単に後付けで移行出来る方法があるなら良いなぁと思ったし、
無いんでないかなーと>>549で言っちゃった。
>>573-576
東京なんちゃら対応のなんちゃらモジュールがCakePHPで動くらしいね。
Cakeはよくよく調べてみるとみんなで結構何とかしちゃってる感がある。
> 既存のDBアクセス周りをラップするクラスを作ればいいんじゃね？
DBの結果セットをmemcachedに移行するというアプローチは、
自分でやった時はうまくいかなかったなあ。
結局、ご指摘の通りにオンメモリにして逃げちゃった。
なので、簡単に後付けで移行出来る方法があるなら良いなぁと思ったし、
無いんでないかなーと>>549で言っちゃった。
>>573-576
東京なんちゃら対応のなんちゃらモジュールがCakePHPで動くらしいね。
Cakeはよくよく調べてみるとみんなで結構何とかしちゃってる感がある。
578 ：nobodyさん：2009/09/06(日) 16:08:50 ID:55qWNNES
チャットプログラム作ってって言われた。相手はシロートさん＆レンタルサーバってコトで、PerlかPHPの二択にほぼ決定。
Perlは正直「使える」程度なんでPHPにしようと思うんだが、Pearを使わないでファイルコピーで設置完了することが可能なFWってあるかな？
一応SymfonyはSandbox使えば可能なのは知ってるが、流石に少々重たいかと思ってね。
・・・ま、「チャットごとき素のPHPで書けよ」ってのは御説ごもっともなんだがｗ、
どうもバリデータやHTML／SQLサニタイズを手で書くのは億劫になってね。
FWに慣れすぎたかもｗ
Perlは正直「使える」程度なんでPHPにしようと思うんだが、Pearを使わないでファイルコピーで設置完了することが可能なFWってあるかな？
一応SymfonyはSandbox使えば可能なのは知ってるが、流石に少々重たいかと思ってね。
・・・ま、「チャットごとき素のPHPで書けよ」ってのは御説ごもっともなんだがｗ、
どうもバリデータやHTML／SQLサニタイズを手で書くのは億劫になってね。
FWに慣れすぎたかもｗ
FWに慣れすぎた人の質問とは思えないｗ
もしかしてPEARしか触ったことないんじゃ？
PEAR(笑)
smarty(笑)
smarty(笑)
ちいたんで萌え萌えチャットを（ｒｙ
>>578
ぜったい釣りだろ、お前w
ぜったい釣りだろ、お前w
あまりにもトンチンカンな PHP 知識。dankogai 疑惑。
lol
どうせ個人的に使うチャットだろうし
全部１クラスにまとめたようなレトロな作りにしても十分じゃね
FTPでアップロードして権限振ったらすぐ使えます、のほうがいいような相手なんでしょ
大体バリデーションつっても、入力文字の<>&あたり置換すりゃ早々問題なんて起きんだろうし
ログだってファイルにはいていいんじゃね、小一時間もありゃ書けるでしょ
つか、578の場合レンタルでも探したほうがいいんじゃねｗ
そっちのほうが間違いなく多機能で安全で優れてるとおもうぞ
全部１クラスにまとめたようなレトロな作りにしても十分じゃね
FTPでアップロードして権限振ったらすぐ使えます、のほうがいいような相手なんでしょ
大体バリデーションつっても、入力文字の<>&あたり置換すりゃ早々問題なんて起きんだろうし
ログだってファイルにはいていいんじゃね、小一時間もありゃ書けるでしょ
つか、578の場合レンタルでも探したほうがいいんじゃねｗ
そっちのほうが間違いなく多機能で安全で優れてるとおもうぞ
>578
fitzgerald。本体が269行しかない。
ttp://www.moongift.jp/2009/06/fitzgerald/
バリデータは存在しないので自分で書かんといけないが。
一番面倒な、入力を一括してフィルタリングする機構はあるのでさほどの手間はない。
あと、エスケープ/サニタイズが面倒なのはお前が阿呆なだけ。
面倒ならエスケープしてからビューに渡す関数とか作れよ。
fitzgerald。本体が269行しかない。
ttp://www.moongift.jp/2009/06/fitzgerald/
バリデータは存在しないので自分で書かんといけないが。
一番面倒な、入力を一括してフィルタリングする機構はあるのでさほどの手間はない。
あと、エスケープ/サニタイズが面倒なのはお前が阿呆なだけ。
面倒ならエスケープしてからビューに渡す関数とか作れよ。
関数を作るのもめんどくせえー
まともなプログラマなら、小規模用の俺俺ライブラリくらい持ってるだろｗ
FWに慣れたっつーより、FWが無ければ何も出来ないの間違いじゃね？
正規表現とかもかけないんじゃね？ｗ
FWに慣れたっつーより、FWが無ければ何も出来ないの間違いじゃね？
正規表現とかもかけないんじゃね？ｗ
「相手はシロートさん」にﾜﾛﾀ
おめーも大差ないですよっと
おめーも大差ないですよっと
PHP使いにまともなプログラマっているの？
いるわけねーだろ
まともという言葉がどこをさすのかによるだろうな
何度目だよ
Regexクラスとかできちゃいそうだよね
まともなプログラマは言語に依存せず、要件に見合ったコードを書く
PHPかどうかは関係無いし、PHPにも職人クラスのPGはいる。
ただ勘違いした「シロートさん」比率が、他の言語より圧倒的に多いｗｗ
PHPかどうかは関係無いし、PHPにも職人クラスのPGはいる。
ただ勘違いした「シロートさん」比率が、他の言語より圧倒的に多いｗｗ
Pealのにわかプログラマに比べればまだマシだけどな
PHPはどうしても冗長だからな。
PHPは取っつきやすいからな。
で、上達するに連れ、言語仕様に不満が出てくる。
そして、他の言語へ移る。
Web用言語の登竜門みたいなもんだから、仕方ないべ。
今更Perlから入る人も少ないでしょうし。
グローバル関数をクラスライブラリ化して、型宣言もアリにして、
OO言語に生まれかわらんかな。
既存のグローバル関数で発生したエラーを例外処理化したライブラリはないかな?
で、上達するに連れ、言語仕様に不満が出てくる。
そして、他の言語へ移る。
Web用言語の登竜門みたいなもんだから、仕方ないべ。
今更Perlから入る人も少ないでしょうし。
グローバル関数をクラスライブラリ化して、型宣言もアリにして、
OO言語に生まれかわらんかな。
既存のグローバル関数で発生したエラーを例外処理化したライブラリはないかな?
WEBの基礎知識をすっ飛ばしちゃうから
登竜門としては Perl/CGI の方が良いと思うけどなぁ。
PHPから始めた人て、HTTP通信のバックエンドや、文字コードを理解して無い人が多いよね
multipartなPOSTデータをパースしたり、URLエンコード/デコードしたり、クッキーやセッションの仕組みを理解してなかったり、etc
バグが発生した時に、原因の切り分けが出来なくて困ってる人をよく見る。
登竜門としては Perl/CGI の方が良いと思うけどなぁ。
PHPから始めた人て、HTTP通信のバックエンドや、文字コードを理解して無い人が多いよね
multipartなPOSTデータをパースしたり、URLエンコード/デコードしたり、クッキーやセッションの仕組みを理解してなかったり、etc
バグが発生した時に、原因の切り分けが出来なくて困ってる人をよく見る。
それは言語関係ないと思うけどな
俺はPHPからだったけどWebカメラいじりたくてソケットから弄りだした
まぁその前がC/C++だったから、文字列の扱いが超簡単で楽だったなぁ
俺はPHPからだったけどWebカメラいじりたくてソケットから弄りだした
まぁその前がC/C++だったから、文字列の扱いが超簡単で楽だったなぁ
変数のスコープが関数単位だから、処理を局所化したコードの書き方が身につかない。
>>603
前半と後半のつながりがさっぱりわからん
前半と後半のつながりがさっぱりわからん
PHPしか知らないとそうなる。
関数内でさらに局所かしたいってこと？
確かにできたほうがいいけど、関数をあまり巨大化させなければそれほど問題にならないのでは？
PHPのだめな所はもっと他にあるだろ
確かにできたほうがいいけど、関数をあまり巨大化させなければそれほど問題にならないのでは？
PHPのだめな所はもっと他にあるだろ
たぶん、複数の関連性の強い関数群と、それらの間だけで欲しいデータとかのこと言ってるんじゃ
ないかな、603は。
PHPだとそれらを別ファイル分けて書いて見通しだけは良くしても、結局includeだから同一ソース
ファイルに全部放り込んでるのと変わらん、データの独立性が…とか言いたいのかも。
まあ、クラス使えばいいと思うけど、そういうのは。
ないかな、603は。
PHPだとそれらを別ファイル分けて書いて見通しだけは良くしても、結局includeだから同一ソース
ファイルに全部放り込んでるのと変わらん、データの独立性が…とか言いたいのかも。
まあ、クラス使えばいいと思うけど、そういうのは。
603はクラスも知らん子ということですか。
CやPerlと同じ。書き手の裁量が大きい。
つまり糞がかけば糞になる程度がやや大きい。
その程度の話なんだが言語やOSの話になると痛いのがわんさか沸いてくる。
つまり糞がかけば糞になる程度がやや大きい。
その程度の話なんだが言語やOSの話になると痛いのがわんさか沸いてくる。
みんな喧嘩すんなよ
スコープが関数単位なのって、PHPとJavaScriptぐらいなものなんだ。もっともJavaScriptですら新しいバージョンじゃブロックスコープになるが。
array array array array がめんどくさい
>>612
えっ？なんだと思ってたの？
えっ？なんだと思ってたの？
>607がアホだという事は分かった。
俺も関数を短くするタイプだから、ブロックスコープはあまり必要性を感じないな。
ブロックの中が10行超えたら大抵メソッド化しちまうから特に困らん。
勿論ブロックスコープが悪いとは思わんが、初心者の学習コストを上げるほどのメリットを感じない。
俺も関数を短くするタイプだから、ブロックスコープはあまり必要性を感じないな。
ブロックの中が10行超えたら大抵メソッド化しちまうから特に困らん。
勿論ブロックスコープが悪いとは思わんが、初心者の学習コストを上げるほどのメリットを感じない。
ブロックスコープってそんなにいいの？何か効果が分かる例出して
行の長さに応じてメソッド化するとか意味不明すぎる
だいたい1メソッド20行超えるようだったら能毎分割できるだろう、
とかみたいな目安の話じゃろ。わりとよく聞く話だとおもうけど
とかみたいな目安の話じゃろ。わりとよく聞く話だとおもうけど
むしろ、途中で変数宣言するとかの方がおかしいと思うのだが
全部関数の初めでやればいいじゃん。
全部関数の初めでやればいいじゃん。
それもなんだかなぁ
関数の最初に全部ってのは廃れたやり方だな
最初に宣言しないと用途わからなくなるくらい冗長ってことだしなぁ
途中で宣言するのは for文とか、カウント系だけかな
あとは全部頭で初期化してる
あとは全部頭で初期化してる
クラスプロパティとかは頭におくけど、
メソッド内のローカル変数なんて必要になったら宣言すりゃいいんじゃね
よほど長ったらしい関数とかを書くとかじゃない限り分けて宣言するメリットなくね
メソッド内のローカル変数なんて必要になったら宣言すりゃいいんじゃね
よほど長ったらしい関数とかを書くとかじゃない限り分けて宣言するメリットなくね
条件によって途中で関数を抜けるような場合は、頭で初期化してしまうと無駄な気分に･･･
宣言と初期化分ければそんなに気にならないけど、あまり意味は無い気もするし。
// $hoge を使わない場合がある。
function hoge()
{
$hoge = new Hoge();
if (xxxx) return;
$hoge->hogehoge();
}
宣言と初期化分ければそんなに気にならないけど、あまり意味は無い気もするし。
// $hoge を使わない場合がある。
function hoge()
{
$hoge = new Hoge();
if (xxxx) return;
$hoge->hogehoge();
}
普通はifとかwhileとかのブロックの中でしか使わない変数は、そのブロックの中で宣言するんだよ。
が、PHPの場合、関数の最初の方で宣言しとくのが分かりやすいと言えば分かりやすい。
が、そうすると変数名の衝突が起きやすいので、長い変数名を使わざるを得ない。よって、記述が冗長になる。
が、PHPの場合、関数の最初の方で宣言しとくのが分かりやすいと言えば分かりやすい。
が、そうすると変数名の衝突が起きやすいので、長い変数名を使わざるを得ない。よって、記述が冗長になる。
ブロックスコープ無いってことは、関数呼び出すときに変数を全部初期化してるんじゃないの？
何かそんな資料を昔見たようなうる覚え
何かそんな資料を昔見たようなうる覚え
お前らそろそろスレ違いに気付け
はぁい
全部グローバル変数にするのが一番かっこいい書き方
C言語って関数スコープだっけ？ ブロックスコープだっけ？
Cはブロックスコープ
ググレカス。
全部関数の先頭で宣言するとか、VBじゃあるまいしｗ
このスレって、伸びてるなと思って覗いたら、フレームワークとは
全く関係ない話題で埋め尽くされてることが多いよな。
相応しいスレはいくらでもあるんだから、そっちでやれや。
全く関係ない話題で埋め尽くされてることが多いよな。
相応しいスレはいくらでもあるんだから、そっちでやれや。
そういやVBもブロックスコープじゃなくって、関数単位だったな。VB.NETはブロックスコープになったんだっけ。
お返事が遅くなって申し訳ない。
・・・まぁ、この流れはある程度想定の範囲内。
フツー、「んなもんスクラッチで書けよ」って思うよなｗ
>>587
相手についての考察は大体そのとおり。だからpear使いたくなかったんよ。
レンタルチャットでは多分無理。少なくともかなりのカスタマイズしないといけないんで、結局手間はあんまり変わらないと思われ。
>>588
これは知らなかった。ORマッパ無しというのもいいかも。
少し調べてみるっす。感謝＞fitzgerald
エスケープ/サニタイズは、まぁPHPは結構便利な関数があるからそんなに面倒ではないんだけどね。
ま、>>578のとおり、そんなにがっちり組む必要もないんだし、
>大体バリデーションつっても、入力文字の<>&あたり置換すりゃ早々問題なんて起きんだろうし
>ログだってファイルにはいていいんじゃね、小一時間もありゃ書けるでしょ
でいいっちゃいいと思うんだがね。
>>590
あることぁあるが、PHP4の時代のヤツなんでねぇｗ＞俺俺ライブラリ
ま、正規表現は確かに苦手だ。eregとpregでビミョーに違うのもややこしいしｗ
・・・まぁ、この流れはある程度想定の範囲内。
フツー、「んなもんスクラッチで書けよ」って思うよなｗ
>>587
相手についての考察は大体そのとおり。だからpear使いたくなかったんよ。
レンタルチャットでは多分無理。少なくともかなりのカスタマイズしないといけないんで、結局手間はあんまり変わらないと思われ。
>>588
これは知らなかった。ORマッパ無しというのもいいかも。
少し調べてみるっす。感謝＞fitzgerald
エスケープ/サニタイズは、まぁPHPは結構便利な関数があるからそんなに面倒ではないんだけどね。
ま、>>578のとおり、そんなにがっちり組む必要もないんだし、
>大体バリデーションつっても、入力文字の<>&あたり置換すりゃ早々問題なんて起きんだろうし
>ログだってファイルにはいていいんじゃね、小一時間もありゃ書けるでしょ
でいいっちゃいいと思うんだがね。
>>590
あることぁあるが、PHP4の時代のヤツなんでねぇｗ＞俺俺ライブラリ
ま、正規表現は確かに苦手だ。eregとpregでビミョーに違うのもややこしいしｗ
>>639
Rubyはブロックスコープだが。
Rubyはブロックスコープだが。
どのフレームワークのコーディングがきれい?
>>642
好みが大きいと思うけど、標準的なPHPという点ではZFかな？
好みが大きいと思うけど、標準的なPHPという点ではZFかな？
ZFはコーディング規約の為のFWと言っても過言では無いからなｗ
あぁ、クエリを弄れる人がいないのか
誤爆スマソ。
使わないのなら関数で処理分けろよ
バグの温床じゃん
バグの温床じゃん
バリデーションとか含めるとどうしても >>627 みたいなコードは発生するよ。
A処理、B処理、C処理を連続して順番に処理する事を保証する場合、
内部的にメソッドを分けたとしても、PGに提供するメソッドは一つにするのが普通だろ。
その場合、途中の処理でこけた場合、どの処理でこけたかを判断する為に、return もしくは throw 等を使う。
それをしない方がバグの温床になると思うんだが･･･
A処理、B処理、C処理を連続して順番に処理する事を保証する場合、
内部的にメソッドを分けたとしても、PGに提供するメソッドは一つにするのが普通だろ。
その場合、途中の処理でこけた場合、どの処理でこけたかを判断する為に、return もしくは throw 等を使う。
それをしない方がバグの温床になると思うんだが･･･
変数の宣言とクラスの宣言を混同してる件について
ん？どこが？
宣言っつーか初期化だろ、Warningでるやつ
1ヶ月でログが20GB超えてたときは流石に吹いたわ
1ヶ月でログが20GB超えてたときは流石に吹いたわ
>>654
あるあるｗ と言いたいが、途中で気がつけよｗ
あるあるｗ と言いたいが、途中で気がつけよｗ
ローテーションして圧縮してたから、まったく気づかなかった
書庫の中身見てはじめて気づいたんだわ
写真とかアップロードするから、容量に関しては無頓着だったし
書庫の中身見てはじめて気づいたんだわ
写真とかアップロードするから、容量に関しては無頓着だったし
mooseのlazyみたいなのがあればいいんだけどな。
Mooseのｌａｚｙって、内部的にはどんな実装になってるの？
お前らいい加減スレ違いに気付け
フレームワークに限らないPHP全般について、うだうだやるのに適切なスレはどこでしょうか。
くだ質か雑談あたりじゃね
フレームワークの設定ファイルってどんな感じがいいの？
・xmlとかでphpソースと別ファイルにする
・phpソースに定数とか連想配列で保存
・xmlとかでphpソースと別ファイルにする
・phpソースに定数とか連想配列で保存
どっちでも便利なほうでいいんじゃ？
>>663
YAMLいいよ、YAML
YAMLいいよ、YAML
xmlよりは扱いやすいよね。
俺もYamlで別ファイル
YAMLですか。
勉強してきます。
勉強してきます。
そこでJSONですよ
JSON の IE 対策の最後の , が保守性低い
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
以下のヤツは俺が使っている設定ファイル・・・を参考に書き直したもの。
ただのコメントが入った設定ファイルように見えるが、これがYAMLの文法なんだぜ。
# 各種プログラムのパス
bin:
sendmail: '/usr/sbin/sendmail'
nkf: '/usr/bin/nkf'
# テンポラリディレクトリ
tmp: '/tmp'
cache:
# キャッシュディレクトリ
dir: "/var/www/html/myapp/cache"
# キャッシュの保持時間(秒)
expires: 604800 # 1 week
そうか？YAMLだと空白とか訳分からんミスでエラーに
なったりする時があるから、JSONの方が好きなんだが。
プログラマならJSONの方が構造が直感的に分かると思うんだが。
一般人の理解しやすさは
YAML > JSON >>>>>>>>>>>>>> XML
プログラムからのいじりやすさは
JSON > YAML >>>>>>>>>>>>>> XML
という感じだと思うんだが。
あと記述する内容によって適したデータ形式があるから
プロジェクトごとに選択するしかないと思う。
なったりする時があるから、JSONの方が好きなんだが。
プログラマならJSONの方が構造が直感的に分かると思うんだが。
一般人の理解しやすさは
YAML > JSON >>>>>>>>>>>>>> XML
プログラムからのいじりやすさは
JSON > YAML >>>>>>>>>>>>>> XML
という感じだと思うんだが。
あと記述する内容によって適したデータ形式があるから
プロジェクトごとに選択するしかないと思う。
俺としては一番理解しやすいのは ini なんだけど。
PHPの関数も用意されてるし
PHPの関数も用意されてるし
俺の場合JSも頻繁に触るから、確実に覚えているJSONの方が都合がいい
YAMLの可読性は素晴らしいとは思うけど、適度に記号入ってた方が好み
YAMLの可読性は素晴らしいとは思うけど、適度に記号入ってた方が好み
あとキーが文字列なので、""で括って、"key":123としないといけないのもちょっといただけない。
単純な設定ならiniファイルかな･･･
複雑な設定ってWEBプログラムではそうそう無いと思うけど。
バリデーションルールを無理矢理YAML化してるの見ると、なんだかなぁと思う。
複雑な設定ってWEBプログラムではそうそう無いと思うけど。
バリデーションルールを無理矢理YAML化してるの見ると、なんだかなぁと思う。
やべ俺シャレで書いたつもりだったのにマジでJSONをconfigに使う人いたんだｗ
YAMLは３年ほど前spycを使ってとり回そうとして挙動不審だったのでいい思い出がない。
みんなYAMLのパーサ何使ってるの？syck? spyc? preg使って自前?
その辺でおすすめあればもう一度トライしてみます。
YAMLは３年ほど前spycを使ってとり回そうとして挙動不審だったのでいい思い出がない。
みんなYAMLのパーサ何使ってるの？syck? spyc? preg使って自前?
その辺でおすすめあればもう一度トライしてみます。
spyc使っているけど、なんか問題ある？
なんか問題あったとして、今は修正されたんじゃない？
と思って今見てみたら、0.4.2がでてる。
パフォーマンス向上とな。入れ替えようｗ
なんか問題あったとして、今は修正されたんじゃない？
と思って今見てみたら、0.4.2がでてる。
パフォーマンス向上とな。入れ替えようｗ
データとして扱うもんならJSON使ってるなってか
フレームワークどころかPHPですらなくなってるぞ
フレームワークどころかPHPですらなくなってるぞ
PHPのフレームワークに詳しいみんなは、ハンバーグ作る時って
牛肉と豚肉の割合どのくらいにしてる？
牛肉と豚肉の割合どのくらいにしてる？
俺もわけわからんエラー出たことあってphpでyaml使うのは好きじゃない
syck と spyc で YAML の互換性がないのはもう直ったの？
あと、YAML ファイルがでかいと解析時間も遅いのが問題。
あと、YAML ファイルがでかいと解析時間も遅いのが問題。
キャシュしないの?
iniかXMLで十分じゃね？
XMLなら内容の不備も事前に見つけられるし・・・
XMLなら内容の不備も事前に見つけられるし・・・
中身が一本のarrayでいいならserializeもいいかも。
>>686
初回の立ち上がりの遅さが気になって
初回の立ち上がりの遅さが気になって
YAMLの遅さが気になる場合は、
serialize/unserializeしてキャッシュするだろ？
設定ファイルなんて頻繁に変更するわけじゃあるまいし。
serialize/unserializeしてキャッシュするだろ？
設定ファイルなんて頻繁に変更するわけじゃあるまいし。
たかが設定ファイルのためにキャッシュ機構を組み込むほど
yamlの利便性>>>arrayなのか？という問題は難しいところ
yamlの利便性>>>arrayなのか？という問題は難しいところ
ここで普通にPHPファイルでイイじゃんとか言ったら叩かれますかw
スタティクファイル読み込みクラスのアダプターとしてYAML読み込みを実装
yamlっつっても、symfonyの設定ファイルみたいに、
そこにphpコードも書けないと不便だよね
そういうことを考えていくと余計に面倒になってくる
フレームワークに元々実装してあるなら使うけど
そこにphpコードも書けないと不便だよね
そういうことを考えていくと余計に面倒になってくる
フレームワークに元々実装してあるなら使うけど
PHPネイティブでiniやXMLがあるのに、YAMLを選択する理由がわからんなぁ･･･。
iniはシンプルかつ、一般的。
XMLは複雑だが、Flash等と親和性がある(扱えるデザイナが多い/開発環境も多い)
JSONはJSとの親和性がある
YAMLは学習及び実装コストに見合うメリットはあるのだろうか？
ミーハーな感じがするわ。
iniはシンプルかつ、一般的。
XMLは複雑だが、Flash等と親和性がある(扱えるデザイナが多い/開発環境も多い)
JSONはJSとの親和性がある
YAMLは学習及び実装コストに見合うメリットはあるのだろうか？
ミーハーな感じがするわ。
JSONより楽ちんなところくらいかな
学習コスト、実装コストってwwww
そんなもん一時間かそこらだろうが。試すだけ試してみりゃいいじゃん。
そんなもん一時間かそこらだろうが。試すだけ試してみりゃいいじゃん。
PHPで完結してるならYAMLなんて使わず素のPHPでいいと思う。順番付のハッシュがある（しかない）PHPの変数構造体は十分分かりやすいと思う。
YAMLは半角スペースで階層を表現してる時点でなぁ･･･
意図しない半角スペースが入っていても値としては正常なモノとして扱われるのが厄介すぎる。
>>698
パーサからの実装を1時間そこらで出来るわけないだろｗ
意図しない半角スペースが入っていても値としては正常なモノとして扱われるのが厄介すぎる。
>>698
パーサからの実装を1時間そこらで出来るわけないだろｗ
すでに実装があるから必要ないだろ。
>>696
iniはセクションがどうとか、データの階層構造で
複雑なものが作れないんだわ。
YAMLだと自分が思ったままの理想のデータ構造そのまま定義できる。
楽なんだよ。
＞＞699
array( array( array( 地獄から抜け出せるぜｗ
iniはセクションがどうとか、データの階層構造で
複雑なものが作れないんだわ。
YAMLだと自分が思ったままの理想のデータ構造そのまま定義できる。
楽なんだよ。
＞＞699
array( array( array( 地獄から抜け出せるぜｗ
arrayの表記がダサいのが一番問題なんだよな
[]とかで表記できたらいいのに
5.3もおもしろ機能ばっかり付けないでそういうの付けろ
[]とかで表記できたらいいのに
5.3もおもしろ機能ばっかり付けないでそういうの付けろ
>>701
どこの誰が作ったかもわからん実装を検証もせず使えるかｗ
どこの誰が作ったかもわからん実装を検証もせず使えるかｗ
>>704
OSから作ってんのか？ それともCPUも？
OSから作ってんのか？ それともCPUも？
>704
じゃあ検証すりゃいいじゃん
少なくとも自分で書くよりは速いぜ
じゃあ検証すりゃいいじゃん
少なくとも自分で書くよりは速いぜ
>>704
PHPも自作なのか
PHPも自作なのか
天才の704さんがぱねぇっす。
もちろん他人の作った飯なんて、米なんてのも食べられないんですよね？
もちろん他人の作った飯なんて、米なんてのも食べられないんですよね？
>>703
はげどうだわｗ
はげどうだわｗ
配列と連想配列の組み合わせとかarrayarrayarrayarrayで書いてて頭がおかしくなる
arrayarrayarrayって書いていると、頭がおかしくなって、あ〜りぃ〜？って言う。
drupal 使っていると、array の array の array の array の array
とか当たり前で目が痛くなってくるｗ
とか当たり前で目が痛くなってくるｗ
>710
function a(){
return func_get_args();
}
というのはどうだろう、今思いついたんで動くかは知らん
function a(){
return func_get_args();
}
というのはどうだろう、今思いついたんで動くかは知らん
有野有野有野うるさいんだよ。お前は有野のなんなんだ！
>>713
a('h' => 'o')
a('h' => 'o')
>715
連想配列は配列ではない(ｷﾘｯ
…正直すまんかった
連想配列は配列ではない(ｷﾘｯ
…正直すまんかった
PHPの場合、連想配列と配列の区別ってないだろ
718 ：nobodyさん：2009/09/11(金) 05:32:45 ID:P+LwJJ6C
>>699
納品先によっては、ソースを直すには抵抗あるけど設定ファイルならOKってところもあるな。
納品先によっては、ソースを直すには抵抗あるけど設定ファイルならOKってところもあるな。
OSやPHPの実装と、YAMLパーサの実装を同じ視点で考えちゃうのか･･･YAML信者は怖いな。
YAMLがメジャーになりうる要素も気配も無いのにね。
YAMLがメジャーになりうる要素も気配も無いのにね。
> YAMLがメジャーになりうる要素も気配も無いのにね。
え？ すでにメジャー・・・
え？ すでにメジャー・・・
何を根拠に
> え？ すでにメジャー・・・
YAML厨乙ｗｗｗ
YAML厨乙ｗｗｗ
array arrayに嫌気がさしたらqiq
qiq は壊れた go-pear.phar や php_pgsql.dll なんかも修正した ( Linux であるような ) ディストリビューションとして配布されてもいいと思う
<自分語り>
とりあえずアンテナ低目の俺の場合、
ini, XML, JSON: ここしばらくの話は分かる程度には知ってた。
YAML: 「え、なにそれ?」とぐぐった
</自分語り>
とりあえずアンテナ低目の俺の場合、
ini, XML, JSON: ここしばらくの話は分かる程度には知ってた。
YAML: 「え、なにそれ?」とぐぐった
</自分語り>
正直設定ファイルごときにパーサ用意するのがめんどい
男は黙ってconfig.inc.php
どうせパスの位置ぐらいしか設定しないから配列地獄とは無縁
男は黙ってconfig.inc.php
どうせパスの位置ぐらいしか設定しないから配列地獄とは無縁
スタティクな値のビューへのアサインに使ってる
パスの設定しかしない人はconfig.inc.phpで問題ないだろう
そこまで変更ぐりんぐりんやらないといけないようなもの作るときにPHP選択しないん
そもそも、変更ぐりんぐりんやることあるのか？
そんあことは少ないし、そういう要件あっても、
フレームワークごとに推奨する実装あるだろ。
フレームワークごとに推奨する実装あるだろ。
そんなに書き換えることもないような設定のためにわざわざパーサ用意するくらいなら
array(array(でいいよ
array(array(でいいよ
ZendFWのドットシンタックスなiniファイルで十分。
db.host = xxxx
db.user = xxxx
db.pass = xxxx
複雑な階層構造を持つ設定なんてそうそう無い。
設定ファイルドリブンな思考はためるべき。
db.host = xxxx
db.user = xxxx
db.pass = xxxx
複雑な階層構造を持つ設定なんてそうそう無い。
設定ファイルドリブンな思考はためるべき。
xxx.iniってファイル名で、中身はPHPでいいよ
設定ファイルにPHPコード書けてしまうと、システム管理者以外に触らせるのが怖くなるから、わけるべき。
ﾝじゃ素直にiniファイルにした方が良いのか
シリアライズフォーマットとして考えると選択肢色々あるけど
設定ファイルならそのFWで標準的なもの使うだけ
設定ファイルならそのFWで標準的なもの使うだけ
iniじゃ複雑なデータ構造が作りにくい
そもそもiniにデータ構造突っ込もうとするのが間違ってると思うが。
自前でデータリストのファイル作れば良いじゃん
自前でデータリストのファイル作れば良いじゃん
自分で、複雑なデータ構造を
パースするようなものを作れと？
そんなもの作るぐらいならYAML使うわｗ
パースするようなものを作れと？
そんなもの作るぐらいならYAML使うわｗ
え、俺なんか難しいこと提案した？
設定ファイルを難読化する気か
難しいことじゃなくて、
車輪の再発明（爆笑）を提案した
車輪の再発明（爆笑）を提案した
<?php
return array
(
設定..
);
で簡単最速
return array
(
設定..
);
で簡単最速
話が激しくループしてるな。
YAMLは言語に依存しないところもいいね。
PHPとPerlとかPHPと、Ajaxとか
そういう風に他言語と組み合わさったシステムでも
共通で使える。
PHPとPerlとかPHPと、Ajaxとか
そういう風に他言語と組み合わさったシステムでも
共通で使える。
それ、YAMLに限ったことじゃない上に、
iniやXMLのがパーサ多いｗｗ
iniやXMLのがパーサ多いｗｗ
たかだか起動時に一度読むだけ、みたいな設定ファイルにパーサ用意すんのもなぁ
ＹＡＭＬはいいとおもうけど、手軽に使えるような土台がまだない感
ＹＡＭＬはいいとおもうけど、手軽に使えるような土台がまだない感
YAMLは新しもの好きのミーハーがはやし立ててるだけだろｗ
・パーサが無い(発展途上)
・スペースインデントが面倒、またはエラーの温床になる。
・読みやすいと言われているが、iniやXMLと比べると読み辛い
・XMLに比べて書くのが楽と言われているが、入力補完/バリデーションの整ったXMLの方が現状では楽。
どう考えても、現状では導入するメリット薄い。
・パーサが無い(発展途上)
・スペースインデントが面倒、またはエラーの温床になる。
・読みやすいと言われているが、iniやXMLと比べると読み辛い
・XMLに比べて書くのが楽と言われているが、入力補完/バリデーションの整ったXMLの方が現状では楽。
どう考えても、現状では導入するメリット薄い。
＞・読みやすいと言われているが、iniやXMLと比べると読み辛い
「人間が」読み辛いという意味なら、XMLの方が読みにくいと思うな俺は。
「人間が」読み辛いという意味なら、XMLの方が読みにくいと思うな俺は。
RubyとかYAMLとか、いろいろ便利だし優れてるっておもうところはたくさんあるけど
導入コストに見合うメリットが足りないんだよねー
導入コストに見合うメリットが足りないんだよねー
YAMLの表記って、XMLビューワーの画面そのものだよなｗ
> ・スペースインデントが面倒、またはエラーの温床になる。
それで思い出したが、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/
それで思い出したが、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/
>>754
お前XML理解してないだろｗ
空白や改行はルートノードの子にあたるテキストノードなんだから別に不思議でも大変でも無いわけだが。
> <tag
> ><tag></tag
> ></tag>
見たことねぇわｗ
パーサ側でホワイトスペース除くなり、該当ノード以外は無視するなりするのが定石じゃね？
お前XML理解してないだろｗ
空白や改行はルートノードの子にあたるテキストノードなんだから別に不思議でも大変でも無いわけだが。
> <tag
> ><tag></tag
> ></tag>
見たことねぇわｗ
パーサ側でホワイトスペース除くなり、該当ノード以外は無視するなりするのが定石じゃね？
非定型ならXML、定型ならYAMLが向いてる
そろそろ>>663からの壮大なスレ違いの流れが100レスを超える
というわけで、
ここからは「自分の好きな設定ファイルのフォーマットを語るスレ」になります。
俺俺フレームワークで用いるもよし
パスの設定のみに使うもよし
PHPのバリデーションコード自体を仕込むもよし
ではどうぞ
ちなみに俺はCSV
というわけで、
ここからは「自分の好きな設定ファイルのフォーマットを語るスレ」になります。
俺俺フレームワークで用いるもよし
パスの設定のみに使うもよし
PHPのバリデーションコード自体を仕込むもよし
ではどうぞ
ちなみに俺はCSV
今オススメのフレームワークってある?
俺はCakeしか使ったことがないけど、サクッと作るのにオススメのフレームワークとか他にある?
俺はCakeしか使ったことがないけど、サクッと作るのにオススメのフレームワークとか他にある?
ちいたん
っていう流れをもう何度見たことか
っていう流れをもう何度見たことか
上の方でfitzgeraldというのが紹介されてて
どうもコードが激しく短いっぽい＆超シンプルっぽいので俺の脳内タスクに記憶され中。
でもCake使いだったら、ちいたんかCIなんだろうな
どうもコードが激しく短いっぽい＆超シンプルっぽいので俺の脳内タスクに記憶され中。
でもCake使いだったら、ちいたんかCIなんだろうな
じゃ Kohana を推す
>>759-761
ありがとう。
fitzgerald、CI、kohana、ちぃたんを検討してみる。
これらでCakePHPよりおすすめな理由ってあれば話題ついでによろしくお願いします。
ちぃたんはまじめにオススメしてくれてるんだろうか・・。
ありがとう。
fitzgerald、CI、kohana、ちぃたんを検討してみる。
これらでCakePHPよりおすすめな理由ってあれば話題ついでによろしくお願いします。
ちぃたんはまじめにオススメしてくれてるんだろうか・・。
調べたらCIから派生したKohanaは面白そうだな〜
CI やるなら Kohana お勧め。
ユーザが少ないのが難点だけど。
ユーザが少ないのが難点だけど。
>>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>
> パーサ側でホワイトスペース除くなり、該当ノード以外は無視するなりするのが定石じゃね？
なんで見やすくしようと思っただけで、
パーサー書き換えないとならんのだ。本末転倒だ。
> 見たことねぇわｗ
リンク先も読めないのかよｗ
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>
> パーサ側でホワイトスペース除くなり、該当ノード以外は無視するなりするのが定石じゃね？
なんで見やすくしようと思っただけで、
パーサー書き換えないとならんのだ。本末転倒だ。
>>765
実践でそんな書き方してる人見たことねーよ。
５年前の情報だよソレ･･･
>> パーサ側でホワイトスペース除くなり、該当ノード以外は無視するなりするのが定石じゃね？
> なんで見やすくしようと思っただけで、
> パーサー書き換えないとならんのだ。本末転倒だ。
リンク先に書かれた書き方が「見やすい」の？
XMLの仕様を理解していればそんな書き方しないで該当ノードのみを抽出するなり、ルートノードに属するテキストノードを削除するなりすると思うんだけど。
ちなみにPHPのXMLパーサは普通に対応している。
PHP読み込み時には空白データとなるが、仕様としては正常なので、
不要ならデータ処理時に省けばいいだけ。
実践でそんな書き方してる人見たことねーよ。
５年前の情報だよソレ･･･
>> パーサ側でホワイトスペース除くなり、該当ノード以外は無視するなりするのが定石じゃね？
> なんで見やすくしようと思っただけで、
> パーサー書き換えないとならんのだ。本末転倒だ。
リンク先に書かれた書き方が「見やすい」の？
XMLの仕様を理解していればそんな書き方しないで該当ノードのみを抽出するなり、ルートノードに属するテキストノードを削除するなりすると思うんだけど。
ちなみにPHPのXMLパーサは普通に対応している。
PHP読み込み時には空白データとなるが、仕様としては正常なので、
不要ならデータ処理時に省けばいいだけ。
>>765
見やすさで言えばリンク先の書き方の方が本末転倒なのではｗ
見やすさで言えばリンク先の書き方の方が本末転倒なのではｗ
>>766
> 、ルートノードに属するテキストノードを削除するなりすると思うんだけど。
そんなことをしたら意味が変わるだろｗ
> 見やすさで言えばリンク先の書き方の方が本末転倒なのではｗ
XMLの限界だよ。
気づけよｗ
XMLは機械が生成して機械が読み込むためのものであって
人間が読み書きするものじゃない。
> 、ルートノードに属するテキストノードを削除するなりすると思うんだけど。
そんなことをしたら意味が変わるだろｗ
> 見やすさで言えばリンク先の書き方の方が本末転倒なのではｗ
XMLの限界だよ。
気づけよｗ
XMLは機械が生成して機械が読み込むためのものであって
人間が読み書きするものじゃない。
反論したいなら、きちんと>>754からの流れを読んで書けよな。
>>768
>> 、ルートノードに属するテキストノードを削除するなりすると思うんだけど。
>そんなことをしたら意味が変わるだろｗ
流れ的に、改行とかスペースだけの不要なテキストノードを削除しろって意味だろ？
データ的には正しい仕様なんだから、パーサのせいじゃない。
>> 見やすさで言えばリンク先の書き方の方が本末転倒なのではｗ
>XMLの限界だよ。
何がどう限界なの？改行や空白だけのデータを保持出来ない形式に変えろって事？
お前の頭の理解の限界ってこと？
>XMLは機械が生成して機械が読み込むためのものであって
>人間が読み書きするものじゃない。
ｗ 普通は機械が読み書きする専用のデータにテキスト形式なんて用いないんじゃね？
人間が読むために視覚化されてるんだろう･･･
>>768
>> 、ルートノードに属するテキストノードを削除するなりすると思うんだけど。
>そんなことをしたら意味が変わるだろｗ
流れ的に、改行とかスペースだけの不要なテキストノードを削除しろって意味だろ？
データ的には正しい仕様なんだから、パーサのせいじゃない。
>> 見やすさで言えばリンク先の書き方の方が本末転倒なのではｗ
>XMLの限界だよ。
何がどう限界なの？改行や空白だけのデータを保持出来ない形式に変えろって事？
お前の頭の理解の限界ってこと？
>XMLは機械が生成して機械が読み込むためのものであって
>人間が読み書きするものじゃない。
ｗ 普通は機械が読み書きする専用のデータにテキスト形式なんて用いないんじゃね？
人間が読むために視覚化されてるんだろう･･･
> 流れ的に、改行とかスペースだけの不要なテキストノードを削除しろって意味だろ？
だからそれやったら意味が違うだろｗ
改行やスペースもも立派なデータだ。
スペース1個と空文字は意味が違う。
だからそれやったら意味が違うだろｗ
改行やスペースもも立派なデータだ。
スペース1個と空文字は意味が違う。
スペースが入っちゃまずいような値とかはAttributeにしときゃ
そもそもこんなアホな話題にならない
っつーかすれ違いいい加減どっか他所でやれよ
そもそもこんなアホな話題にならない
っつーかすれ違いいい加減どっか他所でやれよ
ああ、少し勘違いしていた。そういう話題じゃないか
どっちにしてもスレ違いだけどな
どっちにしてもスレ違いだけどな
話題の発端自体はスレ違いじゃないんじゃね？ >>663
各フォーマットの信者がムキになっちゃってるみたいだけど･･･
個人的にはPHPなら
ini ＞ xml ≧ php ≧ JSON ≧ YAML
の順かなぁ･･･ケースバイケースだろうけど
ｉｎｉはシンプルで誰にでも解りやすいと思う
xmlは親和性の高さと、拡張性の高さが魅力
phpは簡単な設定振り分けコードも埋め込めるのが魅力
JSONはJSとの親和性が高く、他言語含めパーサの選択肢が多いのも魅力
YAMLは発展途上で、パーサ、知名度的に未知数
という感じ
各フォーマットの信者がムキになっちゃってるみたいだけど･･･
個人的にはPHPなら
ini ＞ xml ≧ php ≧ JSON ≧ YAML
の順かなぁ･･･ケースバイケースだろうけど
ｉｎｉはシンプルで誰にでも解りやすいと思う
xmlは親和性の高さと、拡張性の高さが魅力
phpは簡単な設定振り分けコードも埋め込めるのが魅力
JSONはJSとの親和性が高く、他言語含めパーサの選択肢が多いのも魅力
YAMLは発展途上で、パーサ、知名度的に未知数
という感じ
iniは表現力に劣るからなあ。
おまえらもう分かったからバイナリファイル（独自フォーマット）で設定ファイル読み書きしとけ
結局良いとこどりをしたのが
今流行っているYAMLってわけだ。
ini・・・表現力に劣る
XML・・・冗長すぎる。見にくい。
php・・・データではない。コードを入れられてしまう。
JSON・・・コメントが入れられない。
YAML・・・完璧☆
今流行っているYAMLってわけだ。
ini・・・表現力に劣る
XML・・・冗長すぎる。見にくい。
php・・・データではない。コードを入れられてしまう。
JSON・・・コメントが入れられない。
YAML・・・完璧☆
ini、XML、PHP、JSON、CSVの共通の問題点として、
データの中に改行が含まれると
見づらい
YAML・・・完璧☆ﾐ
データの中に改行が含まれると
見づらい
YAML・・・完璧☆ﾐ
>>781がFA
YAML も複数行データは面倒じゃん。
つか、YAML を採用する新規オープンソースは少ない、
というか、ほとんどなくない？
つか、YAML を採用する新規オープンソースは少ない、
というか、ほとんどなくない？
フレームワークの神、Ruby on Railsをなんと心得ておる
>>784
XMLやHTML書いていて、改行が含まれると
<a>
<b>
<c>
<d>改行が
含まれたデータ
</d>
</c>
</b>
</a>
ってなるってわかるよね？
YAMLだとインデントが保てる
XMLやHTML書いていて、改行が含まれると
<a>
<b>
<c>
<d>改行が
含まれたデータ
</d>
</c>
</b>
</a>
ってなるってわかるよね？
YAMLだとインデントが保てる
YAMLは良いとこどりしたつもりが、中途半端になった良い例。
ケースバイケースで ini / XML / php / JSON を使い分ければいい。
YAMLの利点？無いよｗ
プログラム側で無理矢理YAMLをいかそうとする設計にでもしない限りな。
ケースバイケースで ini / XML / php / JSON を使い分ければいい。
YAMLの利点？無いよｗ
プログラム側で無理矢理YAMLをいかそうとする設計にでもしない限りな。
>>785
Rails や Symfony 以外にも
いろんな WAF あるけど、YAML 採用のほうが少ないし、
sf.net にあるのにしても、YAML 採用なんて少ないよね、ということなんだけど。
Rails や Symfony 以外にも
いろんな WAF あるけど、YAML 採用のほうが少ないし、
sf.net にあるのにしても、YAML 採用なんて少ないよね、ということなんだけど。
> YAMLの利点？無いよｗ
結局良いとこどりをしたのが
今流行っているYAMLってわけだ。
ini・・・表現力に劣る
XML・・・冗長すぎる。見にくい。
php・・・データではない。コードを入れられてしまう。
JSON・・・コメントが入れられない。
YAML・・・完璧☆
結局良いとこどりをしたのが
今流行っているYAMLってわけだ。
ini・・・表現力に劣る
XML・・・冗長すぎる。見にくい。
php・・・データではない。コードを入れられてしまう。
JSON・・・コメントが入れられない。
YAML・・・完璧☆
YAMLはシンプルで読みやすく安全でJavaScriptからでも読み込めるライブラリがあるってこと。
設定ファイルでの用途について話してたんじゃねーの？なんだよブラウザって。
iniでは代替できない
JSONやPHPｼﾘｱﾗｲｽﾞは可読性に劣る
つまりXMLかYAML
JAVA世界ではXMLでRORはYAML
JSONやPHPｼﾘｱﾗｲｽﾞは可読性に劣る
つまりXMLかYAML
JAVA世界ではXMLでRORはYAML
YAML厨はこんな所で机上の空論を展開していないで、実績を作ればいいと思うよ。
RubyならYAMLなんだけどな
YAMLは好きだが、PHPだと標準で読み出せないってのが大きな減点材料
サーバ立てるたびにspycインストールするのも面倒だし
YAMLは好きだが、PHPだと標準で読み出せないってのが大きな減点材料
サーバ立てるたびにspycインストールするのも面倒だし
PHPERの実務に役立つ資格って何ですか？
Zendｻｰﾃｨﾌｨｹｰｼｮﾝなんとかとかいう奴いつの間にか終わっててワロタ
Zendｻｰﾃｨﾌｨｹｰｼｮﾝなんとかとかいう奴いつの間にか終わっててワロタ
>>794
それだとこのスレ解散でいいな
それだとこのスレ解散でいいな
>>797
ここはフレームワークを語るスレだ
ここはフレームワークを語るスレだ
Rubyの場合はRubyが使える鯖を探すのから面倒だしどのみち使いづらいわなぁ
>>800
面倒じゃないことって何?
面倒じゃないことって何?
YAML厨は文脈を読まないで揚げ足取りばかり･･･('A｀
だって今時インストールなんてコマンド一行…
spycはファイル1個置いときゃいいだけなのに、
インストールが面倒とか意味わからん。
インストールが面倒とか意味わからん。
>>804
だよね。
ファイル一個置くのも面倒って
自分が作っているプログラムは、
ファイル一個でできているのかと。
自作でもいいからライブラリ使うだろう。
そしたら、ライブラリファイルを一個置くだろう。
それも面倒なんて、どれくらい初心者なんだよｗ
だよね。
ファイル一個置くのも面倒って
自分が作っているプログラムは、
ファイル一個でできているのかと。
自作でもいいからライブラリ使うだろう。
そしたら、ライブラリファイルを一個置くだろう。
それも面倒なんて、どれくらい初心者なんだよｗ
インストールが面倒とかじゃなくて標準で無いのが駄目って言ってるんじゃない？
あ、ここフレームワークスレだったか、スマン。
標準を言い出すとフレームワークどれも使えなくなるな
標準を言い出すとフレームワークどれも使えなくなるな
ZF が標準化されるかなーと思ったけど品質低いよね
標準化されれば使うところ増えるだろうね
OSにバンドルされればサポート対象にもなるし。
OSにバンドルされればサポート対象にもなるし。
Google AppEngineでもYAMLは使われているね。
でもPHPでYAMLを使うのはちょっと敷居高いよ。
YAMLライブラリがRubyでは標準添付、PythonはPyYAMLのできがいいしGoogleAppEngineに含まれている、
でもspycはYAMLパーサとして不完全すぎるし、バグも多い。
YAMLはいい選択肢だと思うけど、PHPでやるのはあまりお勧めしない。
でもPHPでYAMLを使うのはちょっと敷居高いよ。
YAMLライブラリがRubyでは標準添付、PythonはPyYAMLのできがいいしGoogleAppEngineに含まれている、
でもspycはYAMLパーサとして不完全すぎるし、バグも多い。
YAMLはいい選択肢だと思うけど、PHPでやるのはあまりお勧めしない。
> でもspycはYAMLパーサとして不完全すぎるし、バグも多い。
いや（笑） 根拠が書いて無いから誰も信じて無いからそれｗ
いや（笑） 根拠が書いて無いから誰も信じて無いからそれｗ
Zenderとしては有り難いけどね
>>811
お前はSpyc使っているのか？あれはかなりバグ満載だぞ。
ttp://gihyo.jp/dev/serial/01/yaml_library/0004?page=3
Spycで満足しているやつはYAML初心者。
お前はSpyc使っているのか？あれはかなりバグ満載だぞ。
ttp://gihyo.jp/dev/serial/01/yaml_library/0004?page=3
Spycで満足しているやつはYAML初心者。
YAML？ ああ、あれは面白いフォーマットだったよね・・・。
って3年後に言われてるに１ペリカ
って3年後に言われてるに１ペリカ
>>813
>お前はSpyc使っているのか？あれはかなりバグ満載だぞ。
つうか、バグも多いけど、YAMLの便利機能が欠けているのが痛い。使う気になれない。
Spyc使うぐらいならlibyamlの移植を使う。
>>811
>いや（笑） 根拠が書いて無いから誰も信じて無いからそれｗ
おまえがアンカーすら使ってないことはよくわかった。
その程度の知識で「YAML便利」とかほざくな。
おまえみたいなのはな、XMLが登場した時になんでもかんでもXMLで書こうとしたバカどもと同じ水準。
今はYAML覚えたてだから、なんでもかんでもYAMLで書こうとしているだけの単細胞バカ。
ミーハーの行動はYAMLの評判にとって大きなマイナス。YAMLを少しかじった程度でわかった気になるな。
>お前はSpyc使っているのか？あれはかなりバグ満載だぞ。
つうか、バグも多いけど、YAMLの便利機能が欠けているのが痛い。使う気になれない。
Spyc使うぐらいならlibyamlの移植を使う。
>>811
>いや（笑） 根拠が書いて無いから誰も信じて無いからそれｗ
おまえがアンカーすら使ってないことはよくわかった。
その程度の知識で「YAML便利」とかほざくな。
おまえみたいなのはな、XMLが登場した時になんでもかんでもXMLで書こうとしたバカどもと同じ水準。
今はYAML覚えたてだから、なんでもかんでもYAMLで書こうとしているだけの単細胞バカ。
ミーハーの行動はYAMLの評判にとって大きなマイナス。YAMLを少しかじった程度でわかった気になるな。
XMLやJSONと比較して、パーサや情報が熟成されてない時点でなぁ･･･
全体の工数の数％程度の設定ファイルの為に、コストかけるくらいならXML書くわｗ
IDE使えば編集はYAMLより遙かに楽だし
全体の工数の数％程度の設定ファイルの為に、コストかけるくらいならXML書くわｗ
IDE使えば編集はYAMLより遙かに楽だし
お前らたかが設定ファイルでどんだけ熱くなってんだよｗｗ
もうarrayでいいわ
もうarrayでいいわ
XML見づらいっていうけど、
MSのXMLエディタとか使いやすいのあるし
viにこだわらなきゃ楽じゃない？
まぁ普通は設定じゃなくて、データファイルとして使う方が多いと思うが
MSのXMLエディタとか使いやすいのあるし
viにこだわらなきゃ楽じゃない？
まぁ普通は設定じゃなくて、データファイルとして使う方が多いと思うが
ループしてきた
終了
終了
guessworkのPHP5対応版ってどうなったの？
結論
新フォーマットがどんなに優れていようと、学習環境、開発環境、実績が揃わない限り流行り物として終る。
新フォーマットがどんなに優れていようと、学習環境、開発環境、実績が揃わない限り流行り物として終る。
見づらいとかは主観が入るからなぁ
メンバの多数決で決めれば良い
メンバの多数決で決めれば良い
>>815
おろかな君に知恵を授けてあげよう。
バージョン番号。
それがあがると、バグが修正されるんだ。
お前が持ってきたリンク。0.3(beta)
最新、0.4.2
さて、何か言い訳を聞こうか？
どんなバグがあるのかね。
おろかな君に知恵を授けてあげよう。
バージョン番号。
それがあがると、バグが修正されるんだ。
お前が持ってきたリンク。0.3(beta)
最新、0.4.2
さて、何か言い訳を聞こうか？
どんなバグがあるのかね。
カレントバージョンで既知のバグすべてを直してくれる
天才プログラマの>>823がいると聞いてやってきました
天才プログラマの>>823がいると聞いてやってきました
バージョンが上がると、テストもせずにアップデートする>>823がいると聞いてやってきました。
0.4 って時点で未完成もいいところだろ･･･
0.4 って時点で未完成もいいところだろ･･･
能書きはいいから、今現在どんなバグがあるのかいってみな。
0.4.2で十分実用レベルになっているだろ。
YAMLの仕様は全部満たしていない？
だが、他の方法（iniやXML）にその仕様はあるのかと自問しよう。
YAMLは明らかに優れている。
zend studio上でcheckdnsrrを実行すると
undefined functionになるんだけど何でなの
undefined functionになるんだけど何でなの
ttp://www.php.net/manual/ja/function.checkdnsrr.php
| 5.3.0 この関数は、Windows プラットフォームでも動作するようになりました。
5.3.0 以前の Windows で使ってないよね？
| 5.3.0 この関数は、Windows プラットフォームでも動作するようになりました。
5.3.0 以前の Windows で使ってないよね？
>>828
つこうてました
つこうてました
>>830
ドンマイ
ドンマイ
そうだよ。
YAMLは凄いよ。
YAMLは仕様だからね。
ライブラリの問題は別の話。
YAMLは凄いよ。
YAMLは仕様だからね。
ライブラリの問題は別の話。
sprcに実装していない仕様があるとはいえ、
今現在でも、iniなんかより
はるかに優れている現状をみてどう思う？
今現在でも、iniなんかより
はるかに優れている現状をみてどう思う？
バグの出てないバージョンが出てからどうぞ。
仕様上は大は小を兼ねるのかもしれんが、
大抵の設定ファイルなんてiniで事足りる設計になってると思うよｗ
ベンチマークとか取れば、無駄なオーバーヘッドに萎えるかと。
大抵の設定ファイルなんてiniで事足りる設計になってると思うよｗ
ベンチマークとか取れば、無駄なオーバーヘッドに萎えるかと。
array最強でFA
自分はZendFWのドットシンタックスなiniファイルを愛用している
database.host = "hoge"
database.user = "user"
database.password = "pass"
みたいな。
YAMLと比べるとGREPしやすくていいよ。
database.host = "hoge"
database.user = "user"
database.password = "pass"
みたいな。
YAMLと比べるとGREPしやすくていいよ。
>>837
array()が[]で代用できるなら同意
array()が[]で代用できるなら同意
XMLとYAMLはスキーマバリデータが使えるのも大きいよ。
素のPHPのarray()だとリストや階層構造を表現できても検証が微妙。
それに素のPHPでもない限りiniでも普通はの解析結果をキャッシュするでしょ？
まあ設定ファイルなんて各々が好きな形式を使えばいいと思うけど
自分が嫌いだからクソみたいなことを言うだけじゃ議論にならないよね。
素のPHPのarray()だとリストや階層構造を表現できても検証が微妙。
それに素のPHPでもない限りiniでも普通はの解析結果をキャッシュするでしょ？
まあ設定ファイルなんて各々が好きな形式を使えばいいと思うけど
自分が嫌いだからクソみたいなことを言うだけじゃ議論にならないよね。
それならiniでいいじゃんってなる。
XMLのようなデータが簡単に書けるのがYAMLのいいところなんじゃないの？
XMLのようなデータが簡単に書けるのがYAMLのいいところなんじゃないの？
もうYAML
ini くいことさらっと言うな
>>841
同じじゃないよ。
同じじゃないよ。
サーバへのコンテンツのデプロイってどうやってる？
俺はsubversionからupdateしてるけど
一般的な方法ってあるんだろうか
俺はsubversionからupdateしてるけど
一般的な方法ってあるんだろうか
>>846
.svnもアップロードしてるの？
.svnもアップロードしてるの？
ローカルでsvnチェックアウトしてrsync --exclude '.svn'する
httpd.confで.ファイル塞いでるからまず問題ないお
普通にSFTPでうｐ
>>851
それならrsyncの方が・・
それならrsyncの方が・・
ライブにいきなりシンクとだと高負荷のサイトはコードキャッシュが壊れたりするから気をつけよう。
Gitはどうなんかな
svnからわざわざ乗り換えるだけの価値あるの？
svnからわざわざ乗り換えるだけの価値あるの？
スレタイ読めよ
設定情報共有フレームワークとしての
ファイルフォーマットとライブラリをだな・・・・
ファイルフォーマットとライブラリをだな・・・・
俺俺フレームワークよりちょっと規模の大きなもの、社内で共有する規模くらいの作ってる人とかいる?
YAMLなら使ってる
>>857
たぶんいると思うけど、何が知りたいの？
たぶんいると思うけど、何が知りたいの？
ああ、なかまがいた(*'ｗ`)ﾎﾜﾜ
ってやりたいだけ
ってやりたいだけ
俺俺フレームワークって社内で共有するために作る(それも目的の一つ)んじゃないの？
規模が大きいってそういう意味か
フレームワークより規模が大きいってどういうもの？と思ってしまった
フレームワークより規模が大きいってどういうもの？と思ってしまった
cakeってwww配下に全部置けるのか
今まで腐ったケーキと馬鹿にしてたけどこの気軽さはいいかも
今まで腐ったケーキと馬鹿にしてたけどこの気軽さはいいかも
なんだよ、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')。ほんとウンコ。
（つづく！）
>>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')。ほんとウンコ。
（つづく！）
やべー、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行目でエラーになるはずなのにならない。限りなくウンコ。
・ユニコード書式未サポート。ウンコだから期待してない。
・クォートした文字列で「¥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行目でエラーになるはずなのにならない。限りなくウンコ。
>>826顔真っ赤だな
ひどいな
俺は確信した。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はウンコ！にもかかわらず
> 能書きはいいから、今現在どんなバグがあるのかいってみな。
とか自信満々に語るおまえもウンコ！これは絶対！
『（バグを）盛るぜ〜、チョー盛るぜ〜！』
盛り過ぎだろ！
・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はウンコ！にもかかわらず
> 能書きはいいから、今現在どんなバグがあるのかいってみな。
とか自信満々に語るおまえもウンコ！これは絶対！
>>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のどこを見てバグがないと思ったんだろうな。よほど初歩的な使い方しかしてないんだろ。
>・「{ 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のどこを見てバグがないと思ったんだろうな。よほど初歩的な使い方しかしてないんだろ。
>>826
>能書きはいいから、今現在どんなバグがあるのかいってみな。
おまえがそんなこというから、調べてやったよ。
あまりにバグが多いから途中で打ち切ったけど、もっと調べりゃまだまだ見つかるはずだぜ。
さあ弁解を聞こうか。人にここまでさせといてトンズラするなよ？
>能書きはいいから、今現在どんなバグがあるのかいってみな。
おまえがそんなこというから、調べてやったよ。
あまりにバグが多いから途中で打ち切ったけど、もっと調べりゃまだまだ見つかるはずだぜ。
さあ弁解を聞こうか。人にここまでさせといてトンズラするなよ？
>858が何事もなくスルーされ、ようやく収束したと思ったのにわざわざ蒸し返す>864がKYウンコすぎる
もう帰れよお前
もう帰れよお前
痛いとこ突かれちゃったもんね
まぁどっちにしてもYAMLは使うメリットないし、そもそもこの話題はスレ違い
まぁどっちにしてもYAMLは使うメリットないし、そもそもこの話題はスレ違い
いや、カレントバージョンのspycが使えるかどうか
俺も気になってたがテストする気も起きなかったので、
未だに不具合満載ってことが分かっただけでも良かったわ
そういういみではGJ>>864=865=868=869=870
俺も気になってたがテストする気も起きなかったので、
未だに不具合満載ってことが分かっただけでも良かったわ
そういういみではGJ>>864=865=868=869=870
そうだな。ｽﾚﾁでも有用な情報には違いない。
馬鹿は言い過ぎだ正直ｽﾏﾝかった。
馬鹿は言い過ぎだ正直ｽﾏﾝかった。
是非spycスレ立てて続けてくれ。
ここでいいよｗ
spycひどいな
俺も損兄つかん込んでる訳じゃないけど、
どうしてもYAMLで行きたきゃ、symfony付属のパーサ使ってた方がまだ安心できる？
俺も損兄つかん込んでる訳じゃないけど、
どうしてもYAMLで行きたきゃ、symfony付属のパーサ使ってた方がまだ安心できる？
いえ全然
設定ファイルはYAMLでもいいかもしんないけど、データフォーマットでXMLの代替に使うならJSONの方がいいと思う。
CouchDBというドキュメント指向データベースだと、JSONでデータを処理できるのでWebアプリとの親和性が高い。
ttp://wota.jp/ac/?date=20090415
>任意のデータ構造を RESTful に扱うことができるドキュメント指向データベースである CouchDB
CouchDBというドキュメント指向データベースだと、JSONでデータを処理できるのでWebアプリとの親和性が高い。
ttp://wota.jp/ac/?date=20090415
>任意のデータ構造を RESTful に扱うことができるドキュメント指向データベースである CouchDB
もうYAMLはどうでもいいよ。どうせ当分触れる機会なんてない
YAMLはいいよ。どうでもいいのは826。
>>882
ネットで顔色がどうしたとかキモイなお前
ネットで顔色がどうしたとかキモイなお前
>>885
顔色も悪いけど顔がキモイなお前
顔色も悪いけど顔がキモイなお前
「えんがちょえんかちょえんがちょー」
「うるせーお前のかーちゃんでーべーそー」
レベルだな
「うるせーお前のかーちゃんでーべーそー」
レベルだな
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
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
APCやZendOptimizer入ってないものでテストされても・・・
あ、APCはあるのか
後はZendOptimezer
後はZendOptimezer
なんで 2003 年のベンチマークか聞きたい
公式サイトをみると
「Zend Optimizerは、PHPコードの最適化を行ない実行速度を
数％から数十％まで高速化します。」
PHPとASP.NETで10倍以上のスピード差があるならば、Optimizerで
数十パーセント速くなったところで、性能ではASP.NETの
足元にも及ばない気がする。
LAMPを使っているといっていた楽天もショッピングサイトでは
phpの拡張子が見当たらない。
性能面でPHPは使えなかったということなのかな
「Zend Optimizerは、PHPコードの最適化を行ない実行速度を
数％から数十％まで高速化します。」
PHPとASP.NETで10倍以上のスピード差があるならば、Optimizerで
数十パーセント速くなったところで、性能ではASP.NETの
足元にも及ばない気がする。
LAMPを使っているといっていた楽天もショッピングサイトでは
phpの拡張子が見当たらない。
性能面でPHPは使えなかったということなのかな
拡張子ｗ
拡張子て
>>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
>>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
なに？UNIX系は拡張子などないとかいいうつまらんツッコミ？
PHPが低性能すぎてまったく反論できないから、つまらんところに
ツッコミいれることしかできないんですね。
PHPが低性能すぎてまったく反論できないから、つまらんところに
ツッコミいれることしかできないんですね。
「UNIX系は拡張子などない」ｗ
いいんじゃない。
PHP は ASP より性能低いで。
ASP で開発すればいいんだよwwww
PHP は ASP より性能低いで。
ASP で開発すればいいんだよwwww
>>898
wwwつけてるけどあんたがASP, ASP.netをまったく理解して
ないのはわかった。
PHPはASPよりは速い。
ただASP.netには性能面で、完敗。
ASPとASP.netは完全に別物。パフォーマンスもまったく違う。
wwwつけてるけどあんたがASP, ASP.netをまったく理解して
ないのはわかった。
PHPはASPよりは速い。
ただASP.netには性能面で、完敗。
ASPとASP.netは完全に別物。パフォーマンスもまったく違う。
拡張子で腹筋が崩壊した
拡張子わろたｗｗｗ
拡張子のなにがおもしろいの？
アプリケーションサーバがファイル名から予めデータの
種類がわかれば、最適化した処理ができるんだから、
パフォーマンス向上するでしょ。
IISはそうなってる。
まさかPHPのエンジンはやってないの？
なにがおかしいのかさっぱり。
アプリケーションサーバがファイル名から予めデータの
種類がわかれば、最適化した処理ができるんだから、
パフォーマンス向上するでしょ。
IISはそうなってる。
まさかPHPのエンジンはやってないの？
なにがおかしいのかさっぱり。
予め判ってるんだったら書き換えたって問題ないでしょｗｗｗ
>>903
なんだ、アウトプット時には書き換えできるとかそんな話？
それだけで笑ってたのか。あほらし。
レンダリング後のファイル名変換ならたしかIISでもできる。
できるけど、変えないほうがパフォーマンス上はいいでしょ。
ファイル名からphpってばれたら恥ずかしいから、.php以外に変えるんですね。
サイト訪れた人が、「PHP（笑）」って腹筋が崩壊しちゃうからなww
なんだ、アウトプット時には書き換えできるとかそんな話？
それだけで笑ってたのか。あほらし。
レンダリング後のファイル名変換ならたしかIISでもできる。
できるけど、変えないほうがパフォーマンス上はいいでしょ。
ファイル名からphpってばれたら恥ずかしいから、.php以外に変えるんですね。
サイト訪れた人が、「PHP（笑）」って腹筋が崩壊しちゃうからなww
コンパイルして実行する言語と、スクリプト言語の速度を比較しても意味ない。
>>905
.net frameworkの仕組みまったくわかってないでしょ。
.net系言語、クライアントPCで実行する場合とasp.netでは動きはぜんぜん違う。
asp.netで使用される時のC#.net、VB.netはPHPと同様にスクリプト言語（注）
それでもPHPより10倍以上速い。
>887の2番目のベンチみるとわかるが、C++のCGIに匹敵するスピードを
叩き出してる。
（注）
(最初の実行時にアプリケーションサーバ(IIS)上でプリコンパイルはされるが、
それくらいはPHPでもやってるでしょう？)
.net frameworkの仕組みまったくわかってないでしょ。
.net系言語、クライアントPCで実行する場合とasp.netでは動きはぜんぜん違う。
asp.netで使用される時のC#.net、VB.netはPHPと同様にスクリプト言語（注）
それでもPHPより10倍以上速い。
>887の2番目のベンチみるとわかるが、C++のCGIに匹敵するスピードを
叩き出してる。
（注）
(最初の実行時にアプリケーションサーバ(IIS)上でプリコンパイルはされるが、
それくらいはPHPでもやってるでしょう？)
で、PHPフレームワークスレでそれをどう活用したいんだ？
まーたでたよゲイツ信者
あの界隈はそれだけでひとつに纏まってんだからいちいち他所に沸くなよ
あの界隈はそれだけでひとつに纏まってんだからいちいち他所に沸くなよ
ド素人どんだけ〜w
.aspだろうが.phpだろうが.cgiだろうが、隠蔽するのはプロなら普通。
（今どきは素人さんでもやってるが。ちょっと調べればできちゃうし）
デザイン的に言えば、拡張子が出ているのはダサいという風潮がある。
技術的に言えば、URLを実装技術に依存させるのは将来的に困る可能性がある。
加えて、セキュリティ的にも望ましくない。PHPだろうがASPだろうがIISだろうが、可能な限り隠蔽するのが望ましい。
（今どきは素人さんでもやってるが。ちょっと調べればできちゃうし）
デザイン的に言えば、拡張子が出ているのはダサいという風潮がある。
技術的に言えば、URLを実装技術に依存させるのは将来的に困る可能性がある。
加えて、セキュリティ的にも望ましくない。PHPだろうがASPだろうがIISだろうが、可能な限り隠蔽するのが望ましい。
だいたいフレームワーク使うとスマートURLになるしね
楽天のサイトってどんな拡張子だったか
思い出してみろｗ
思い出してみろｗ
漢は黙って.exe
標準のPHP（mod_php）はリクエストの度にソースコードをパースして構文解析、中間コードがコンパイルされて、実行される。毎回そう。
バイナリコードが実行されるASP.NETとは土俵が違う。
とはいえ、.NETアプリケーションがC++のアプリケーションに速度で匹敵するわけない。
もっともこれはウェブサーバやアプリケーションサーバの性能を考慮に入れない場合。
そして、処理内容が言語の速度を問う程に十分複雑な場合の事。
Cでウェブサーバ自体作ってしまえばそれが一番速いし、HELLOWORLD程度のウェブページをCGIで動かすぐらいなら、PHP（mod_php)の方が速い。
バイナリコードが実行されるASP.NETとは土俵が違う。
とはいえ、.NETアプリケーションがC++のアプリケーションに速度で匹敵するわけない。
もっともこれはウェブサーバやアプリケーションサーバの性能を考慮に入れない場合。
そして、処理内容が言語の速度を問う程に十分複雑な場合の事。
Cでウェブサーバ自体作ってしまえばそれが一番速いし、HELLOWORLD程度のウェブページをCGIで動かすぐらいなら、PHP（mod_php)の方が速い。
遅いで有名なRoRで作ったtwitterがあれだけのサービスになったんだから
phpで何の問題もないわ
phpで何の問題もないわ
今でもAPIコケまくってるけどな・・・
Twitterって今はもうRoRじゃないんでしょ？
今はcakePHPらしい
まじ？wwww
俺釣られた？
俺釣られた？
結局DBか帯域or接続数辺りがボトルネックになってくるしな。
コードの処理時間がネックになる例ってあまり聞かない。ImageMagickとか使うと話が違うが。
コードの処理時間がネックになる例ってあまり聞かない。ImageMagickとか使うと話が違うが。
>915
PHPってプリコンパイルされないの？と驚いてぐぐってみたら
Zend Optimizer使うとプリコンパイルされるような事がかいてあった。
標準構成でプリコンパイルしてくれないってのは遅れてんね
.NET frameworkで動くIronRubyにも性能面で負けちゃうんじゃないの。
PHPってプリコンパイルされないの？と驚いてぐぐってみたら
Zend Optimizer使うとプリコンパイルされるような事がかいてあった。
標準構成でプリコンパイルしてくれないってのは遅れてんね
.NET frameworkで動くIronRubyにも性能面で負けちゃうんじゃないの。
しかし、PHP系のスレは香ばしい奴しかいないのが哀しいな･･･
ASP.net と PHP 比べて云々言う奴は、
WEBサーバ含めてCでフルスクラッチすればいいんじゃないかね？ｗ
PHPの動作速度で実用上問題になるサイトはほとんど無い。
大抵はDBや通信部分のボトルネックが大きい。
ASP.net と PHP 比べて云々言う奴は、
WEBサーバ含めてCでフルスクラッチすればいいんじゃないかね？ｗ
PHPの動作速度で実用上問題になるサイトはほとんど無い。
大抵はDBや通信部分のボトルネックが大きい。
なんで ASP.NET が普及していないのかは考えないんだね
ASP.NETは普及してると言えば普及してる。PHPが選ばれるケースとは要求条件が違うだけ。それはJava EEとかもそう。
だから、普通に考えたら、確かにAPCとかのキャッシュを標準にすると思う。mod_perlとかmod_railsとか、Javaのコンテナとか、それが当たり前だし。
が、PHPの場合、極力簡単にウェブアプリを作る事だから。開発者にキャッシュを使いこなす事を求めるより、デプロイの単純さを選択してるんだろう。
が、PHPの場合、極力簡単にウェブアプリを作る事だから。開発者にキャッシュを使いこなす事を求めるより、デプロイの単純さを選択してるんだろう。
facebookなんてトップページhome.phpだぜ
2億5千万が利用してるサービスがPHPで拡張子出してる。
URIは変わらない事が大事なのであって余計な情報を見せないようにとか結構どうでもいい話。
2億5千万が利用してるサービスがPHPで拡張子出してる。
URIは変わらない事が大事なのであって余計な情報を見せないようにとか結構どうでもいい話。
ホントこのスレって、スレ違いの話題で埋め尽くされてるよな。
スレ違いの話題を延々してる奴、いい加減にしとけよ。
スレ違いの話題を延々してる奴、いい加減にしとけよ。
古いどうしようもないサイトはそうだけど
そんなサイトいじってるだけの仕事なんて日に日に減ってって後ないじゃん
新しいの立ち上げるときもそんなURIつかってたら客に笑われるわｗ
だいたい昨今のフレームワークならこのあたりの機能はついてるし、別段難しいもんでもないよな
そんなサイトいじってるだけの仕事なんて日に日に減ってって後ないじゃん
新しいの立ち上げるときもそんなURIつかってたら客に笑われるわｗ
だいたい昨今のフレームワークならこのあたりの機能はついてるし、別段難しいもんでもないよな
イントラ用途っていう話なんじゃないのかな？
>>930
俺が知ってるのはソフマップぐらいだなあ
俺が知ってるのはソフマップぐらいだなあ
>>925
IIS(ASP.net)はWEBサーバのシェア20〜25%。
商用製品のWEBサーバとしてはトップ。
当然ながらイントラネット内の業務用ならもっとシェア高い。
大規模サイトなんていくらでもあるよ。特に欧米。非MS系だと
知る限りで一番トラフィック大きそうなところは、オークションのeBayかな
MS系だけでもHotmailやらLive Search(Bing)やらは相当なトラフィックかと。
IIS(ASP.net)はWEBサーバのシェア20〜25%。
商用製品のWEBサーバとしてはトップ。
当然ながらイントラネット内の業務用ならもっとシェア高い。
大規模サイトなんていくらでもあるよ。特に欧米。非MS系だと
知る限りで一番トラフィック大きそうなところは、オークションのeBayかな
MS系だけでもHotmailやらLive Search(Bing)やらは相当なトラフィックかと。
eBay も MS 系だからなぁ。
大規模サイトでいくらでもあるなら 3 つ挙げてよ。
大規模サイトでいくらでもあるなら 3 つ挙げてよ。
お前ら
他所でやれ
他所でやれ
まったくだ。
絵BayはMS系の会社ではないだろ。
大規模サイトでたくさんあるって言葉が信じられないなら、
WEBサーバのシェアと、ASP.NETのベンチマーク結果いろいろ調べれば。
シェア20%以上あって、ベンチマークも最速なんだから、
多くの導入事例があることくらい容易に想像できそうなもんだけど。
大規模サイトでたくさんあるって言葉が信じられないなら、
WEBサーバのシェアと、ASP.NETのベンチマーク結果いろいろ調べれば。
シェア20%以上あって、ベンチマークも最速なんだから、
多くの導入事例があることくらい容易に想像できそうなもんだけど。
数字はお金のチカラですね、わかります。
捏造可能なベンチマークやシェアの数字に必死にしがみついて生きていけ。Ｂ層さん？
捏造したという話そのものが
捏造
捏造
結論
オラはアパッチじゃなきゃいやずら
ウララー
いなりずし1000個食うタイ
オラはアパッチじゃなきゃいやずら
ウララー
いなりずし1000個食うタイ
ヨドバシドットコムって、ポイントがリアル店舗と共通じゃん。これは凄い。
リアル店舗のPOSとウェブが連動しなければならない。そうなると業務アプリに対応出来るJavaかMS系を採用することになる。
PHPはビジネスロジックが簡単なウェブサイトを作るのに向いてる。
何てことない掲示板サイトだってトップクラスのアクセスを集めることもある。そういうのにPHPは向いてる。
アクセスをさばくのはインフラの問題であって、言語が影響する事は少ないから。すると、PHPは無料だし、PHP開発者も単価が安いので、PHPが選ばれる。
リアル店舗のPOSとウェブが連動しなければならない。そうなると業務アプリに対応出来るJavaかMS系を採用することになる。
PHPはビジネスロジックが簡単なウェブサイトを作るのに向いてる。
何てことない掲示板サイトだってトップクラスのアクセスを集めることもある。そういうのにPHPは向いてる。
アクセスをさばくのはインフラの問題であって、言語が影響する事は少ないから。すると、PHPは無料だし、PHP開発者も単価が安いので、PHPが選ばれる。
> ヨドバシドットコムって、ポイントがリアル店舗と共通じゃん。これは凄い。
実はウェブの注文を店員がレジでポイント加算しているだけ。
ソース俺
ぜんぜん、すごくないよーｗ
実はウェブの注文を店員がレジでポイント加算しているだけ。
ソース俺
ぜんぜん、すごくないよーｗ
マジレスすると、POSといってもレジは関係なく、
POSのサーバー（データベースにRDBMSを使用しているだろう）
にアクセスすれば良いだけだからPHPからポイント共通処理は行える。
言うまでも無いが、MySQL、PostgreSQLだけでなく、商用のOracleやMS SQL Serverにも
PHPからアクセスできる。
POSのサーバー（データベースにRDBMSを使用しているだろう）
にアクセスすれば良いだけだからPHPからポイント共通処理は行える。
言うまでも無いが、MySQL、PostgreSQLだけでなく、商用のOracleやMS SQL Serverにも
PHPからアクセスできる。
>>943
みたいな素人は本当に恥ずかしい。
JavaかMS系にしなくてはならない理由を明確に書いてみろよｗ
店舗POSとの連携システムをいくつか作ってきているが、
大抵はRDBMS経由での連携になるので開発言語は特に関係無い。
みたいな素人は本当に恥ずかしい。
JavaかMS系にしなくてはならない理由を明確に書いてみろよｗ
店舗POSとの連携システムをいくつか作ってきているが、
大抵はRDBMS経由での連携になるので開発言語は特に関係無い。
>>926
まあそれでも需要はあるわけでPHP6からAPCが標準だそうな
まあそれでも需要はあるわけでPHP6からAPCが標準だそうな
>950
開発速度が同じならな
あと人間の確保のしやすさ
開発速度が同じならな
あと人間の確保のしやすさ
>951
PHPの方がJavaやC#より開発効率がよいとでも？
エンジニアが確保しやすいとでも？
PHPの方がJavaやC#より開発効率がよいとでも？
エンジニアが確保しやすいとでも？
小規模なサイトならスクリプト系の言語の方が工数は少なくなるが、
ある程度の規模以上であれば、あまり言語は関係なくなるような気がする。
ある程度の規模以上であれば、あまり言語は関係なくなるような気がする。
Javaは分からんでもないが、C#でまともにプログラムできる人間に会ったことが無いわ
>952
・（小規模であれば）開発効率が良い
・（単価を考慮すれば）人間が確保しやすい
開発速度にしたって、環境構築まで勘定に入れれば速かろうよ
いや、俺は自社サービス系だから、BtoB系の事情は良く分からんが
・（小規模であれば）開発効率が良い
・（単価を考慮すれば）人間が確保しやすい
開発速度にしたって、環境構築まで勘定に入れれば速かろうよ
いや、俺は自社サービス系だから、BtoB系の事情は良く分からんが
適材適所。システムの規模というより、
多くのレンタルサーバーで動かそうとしたら
PHPしか選択肢が無いのが現実。
多くのレンタルサーバーで動かそうとしたら
PHPしか選択肢が無いのが現実。
うちは、Web系の仕事はPHPも.NETもJavaもやっているSIなんだけど。
PHPの最大のメリットは、開発効率や人間の単価なんかではなくて、
小規模ならレンタル鯖でも動かせる、大規模でもライセンス料がかからない、
Apacheが動く鯖さえ用意すれば済むと言うところだな。
ちなみに、BtoBではJavaが必要っていうのは完全に思い込みだと思う。
あと、イントラ用途での.NET(Web Forms)の生産性は、用途によっては
他の追随を許さないレベル。
PHPの最大のメリットは、開発効率や人間の単価なんかではなくて、
小規模ならレンタル鯖でも動かせる、大規模でもライセンス料がかからない、
Apacheが動く鯖さえ用意すれば済むと言うところだな。
ちなみに、BtoBではJavaが必要っていうのは完全に思い込みだと思う。
あと、イントラ用途での.NET(Web Forms)の生産性は、用途によっては
他の追随を許さないレベル。
うちもPHP/.NET/Java何でもやるけど、
PHPのメリットはサーバ代などが安いから利益率を高められること。。
PHPのメリットはサーバ代などが安いから利益率を高められること。。
.NETはライセンス無視しまくってやっと利益が出る程度だかんなぁ
あー、はやくこんな中華系の糞会社やめてぇって毎日思いながら
割れものつかって開発してるぜ
それはさておき、フレームワークといえば、
仕事でってのはまだなさそうだけど個人でYiiつかってみてるひとっている？
あー、はやくこんな中華系の糞会社やめてぇって毎日思いながら
割れものつかって開発してるぜ
それはさておき、フレームワークといえば、
仕事でってのはまだなさそうだけど個人でYiiつかってみてるひとっている？
開発費の回収は後々のサービス費1年ぐらいでやっと回収できるっつーかそういう計算なんだもんな
最初の費用だけで回収できるのは結局使いまわしできる案件だけ、そしてそんな案件10もねぇよ・・・
最初の費用だけで回収できるのは結局使いまわしできる案件だけ、そしてそんな案件10もねぇよ・・・
おまえらエンジニアだろ。コストなんてどーでもいいじゃん。
言語としてPHPよりC#の方がおもしろいぜ。
言語としてPHPよりC#の方がおもしろいぜ。
ぉぃｗ逆だろｗ
うむ、逆だなｗ
まあ、俺も正しいことと楽しいことが違う人間だし、PHPよりもC#の方が好きだけど。
まあ、俺も正しいことと楽しいことが違う人間だし、PHPよりもC#の方が好きだけど。
C#は後発だけあってよく出来てる。LINQとかな。PHPは簡単に覚えられるってこと以外、まるでメリットないと思う。仕事だから使ってるけど。
C#はGC使わなくするオプション付いた？
以前それで動かなかったから捨ててたんだが
以前それで動かなかったから捨ててたんだが
>>965
オマエは.NETを使わなくてもいいよ。
オマエは.NETを使わなくてもいいよ。
PHPの方がおもしろいとか言ってる奴なんなのｗｗｗ
そんなこと言ってるやついるのか？ｗ
つーか、再三スレ違いと指摘されてもグダグダくだらん話題で
引っ張る奴こそなんなの？ だな。
引っ張る奴こそなんなの？ だな。
たまにフレームワークの話がでてきても〜使ってる人いる?のレス付かずでお終い
で、PHPのフレームワークで決定版って何だろ。
RORみたいな定番ってないのかな。Zendも、現場
じゃあまり使われてないみたいだし。
または、Zendベースのさらなるフレームワークとか、
CMSとかないのかな。
RORみたいな定番ってないのかな。Zendも、現場
じゃあまり使われてないみたいだし。
または、Zendベースのさらなるフレームワークとか、
CMSとかないのかな。
>>970
yiiについてはちらほらと話題に出てきては（使ってる人間少なすぎて）レスつかずだね
俺も気になってはいるが、Cakeから離れられない
RoRみたいな決定版がないのも、Webアプリ使用前提で発展してきたPHPならではともいえる。
yiiについてはちらほらと話題に出てきては（使ってる人間少なすぎて）レスつかずだね
俺も気になってはいるが、Cakeから離れられない
RoRみたいな決定版がないのも、Webアプリ使用前提で発展してきたPHPならではともいえる。
恐らくPHPのフレームワークに決定版など出てこない
分散的にそれぞれが発展するものと思われ、またそれでいいのではと
分散的にそれぞれが発展するものと思われ、またそれでいいのではと
ところで、俺俺フレームワークもどきの話をしないか？
お断りです
Ruby界隈も最近はRoRオンリーってわけじゃないけどな。
Cake同様の「全部入り」に不満を抱いた連中が軽量フレームワークに動いてる。
PHPにもその流れはある程度影響してるが。
Cake同様の「全部入り」に不満を抱いた連中が軽量フレームワークに動いてる。
PHPにもその流れはある程度影響してるが。
シナトラのこと？
Zendはモデルへのアクセス方法を早急に提供しなさい
>>974
設定ファイルのフォーマット以外を頼む
設定ファイルのフォーマット以外を頼む
Rubyはこれ以上伸びそうにもないな。2年くらい前のRailsブームがピークだったな。楽天が松本呼んだりしてたが、あれまだやってるんだろうか。
俺俺フレームワークって、各種オープンソースなライブラリを使いやすい形にラップした物が多いから公開しにくいってのもあるよねぇ･･･
俺が作ってるのは
シンプル、軽量、1ディレクトリアップロードするだけで動作、コードの自動生成は無い代わりにデバッグ機能が充実
で、データベースやHTTPクライアント等の実装に手間がかかる部分はZendFWを組み込んでる。
フレームワークというより、
個々の手法で最初に行っている初期化処理を纏めたようなクラス群か。
俺が作ってるのは
シンプル、軽量、1ディレクトリアップロードするだけで動作、コードの自動生成は無い代わりにデバッグ機能が充実
で、データベースやHTTPクライアント等の実装に手間がかかる部分はZendFWを組み込んでる。
フレームワークというより、
個々の手法で最初に行っている初期化処理を纏めたようなクラス群か。
PHP Rules ってのはどうなんでしょ
>>982
PHP最高！
PHP最高！
>>981
すぐに公開すべき
すぐに公開すべき
どんな言語でもデバッグするためのライブラリを
標準で用意してほしい。
print_rみたいに、クラス・構造体の内容を
見やすく表示したり、
PHPの話じゃないけど、定数の値から、定数名を表示したり。
標準で用意してほしい。
print_rみたいに、クラス・構造体の内容を
見やすく表示したり、
PHPの話じゃないけど、定数の値から、定数名を表示したり。