1 :
nobodyさん :
2009/09/26(土) 05:55:43 ID:Z4zintKr 前スレ pc11.2ch.net/test/read.cgi/php/1237825268/
2 :
nobodyさん :2009/09/26(土) 05:56:56 ID:Z4zintKr
主なフレームワーク * symfony * CakePHP * ZendFramework * CodeIgniter
噂には聞いてたけど cakeのコードきっついすなー なんでこんなのが人気あるんだ
PHPと何の関係があるの? って笑えばいいのかな?
>>3 コードの質もわからないバカが多いからだよ。
cakeはメソッドの名前とかが微妙におかしい 英語がろくに使えない中国人が付けたみたいな感じ
たとえば?
isFieldErrorとか
beforeFilterもいい名前じゃないな 何の前なのか明示した方がいい
で、どのフレームワークが一番いいの?
これからはじめるならYiiもいいかもしれないよ
yiiもドキュメント見るとなんかダサい感じ
面接で、使ったことあるフレームワークとか聞かれたとき、 Yiiって言いにくいよな、なんかショッカーの雑魚戦闘員っぽくて。
>>18 いくら何でもこんな表じゃ比較できないだろうw
やっぱり使ってみないと分からないよな
PHP4準拠だったり、マジックメソッド多用してたり、グローバルスコープに関数や定数を定義しまくっているFWは論外だと思う。 特にマジックメソッドはIDEとの親和性も悪いし、エラーの温床になりやすい。
それってcakeしかねーじゃん!
マジックメソッドは使わなければ良いだけじゃね?
cakeはレンタルサーバーでも使いやすいから人気になっただけだな
つまり、そのほかのフレームワークは レンタルサーバーでは使いにくいといいたいわけです。
PHP使ってる人のPGとしての意識が低いだけっしょ。 コード品質より、楽さを求める人が多いからcakeを選択する人が多い、と。
他のフレームワークよりcakeは楽できるの?
最初に覚えてからもう新しいの覚えることができなくなった頭がお年寄りになった人たちには楽だよ
cake食い過ぎて糖尿病!
すみません、フレームワークを勉強しようと思っているのですが、ZendとCakeってどう違うのでしょうか? まだ良く分かっていないのですが、例えばライブラリのように2つを一緒に使うとかいうような事も出来るのでしょうか? 関数、変数名が干渉してしまってどちらか一方だけになるとかあるのかなぁ、と思っています。
cakeは「名前空間がぶつからないようにする」という配慮自体が欠けてる、全体的に。
Zend 疎結合 Cake 密結合
>>30 そ、それはまずいですね
しかし使っている人も多いようなのである程度注意していれば問題は無いのでしょうが、ちょっとした事でオーバーライドとかのバグになりそうですね
>>31 おおっ、簡潔でいて的を射ていそうな表現ですが
自分にはちょっと分かりにくかったです
Zendは互いが干渉しにくい為にバグやオーバーライド等が少ない代わりに構文はやや複雑になり、
Cakeは色々なメソッドやらハンドラが密に干渉していて、簡単な構文になりやすいという事でしょうか?
ふえっ? すみません、では違いが分かりません どのように2つは違うのでしょうか・・・ ごめんなさいあまり知識が無いもので
Zendは次世代PEAR(ライブラリ集)、CakeはPHP版RoR。 設計思想からして違う。 実際に使ってみると、 Zendはフレームワークを作る為のライブラリ集、 基本的な機能は揃っているが導入時にある程度のコードを書く必要がある。 反面、自分の使いやすい形式のFWに仕立て上げる事が出来る。 疎結合なので、使いたいクラスを学ぶだけで簡単に導入出来る。 Cakeは決められたルールに従えば、書くコードが少なくてすむ。 反面、ルールから外れた事しようとすると面倒になる。
>>35 よく分かりました
説明有難うございました
コンポーネントとか使い始めると名前衝突の可能性がぐんと上がるかも。>Cake Cake3ー!早く来てくれー!
名前衝突とか気にするなら、 最初からcake以外のフレームワーク使うのが吉 せっかくいろいろ種類が出てるんだから、 他のフレームワークも盛り上がって欲しい まあおれはcake使うけど
PHPに名前空間がサポートされたら、 Cakeは逆にシンプルな関数名で良いといわれるようになる。 そこまで先を見ていたのだよ。
PHP5.3から名前空間サポートされましたけど。
PHP5.3の付け焼き刃な名前空間使うくらいなら、 クラスにパッケージ接頭子付ける方がまし。
Zend とか異常に長いのなかった あーゆーのは嫌だなぁ
名前空間がサポートされたとしてもcakeの定数名はないわ
>>42 ネームスペース使っても
new Zend_Db_Adapter_Abstract(); が new Zend\Db\Adapter\Abstract();
になるだけだぜ?
同一パッケージや、useでエイリアス貼ればいいんだろうけど・・・それをやり始めると名前衝突が避けられなくなるという罠。
Zendの命名形式はいいけど、サブパッケージを掘りすぎなのが問題だと思う。
Zend_DbAdapterAbstract
Zend_ControllerFront
みたいにcamelCase使ってもう少し階層数を下げれんもんだろうか。
で、業界で一番使われているフレームワークはどれなの?
言う程フレームワークは浸透していないよw 習コストかかるし、FW自体をまともに理解出来る人材も少ない。 結果社内開発のシンプルなライブラリ集みたいなものが多用される事になる・・・
>>44 Zend_DbAdapterAbstract
こんなんじゃオートローダー作りにくいし、(現状だとPEAR含めてオートローダーが共用できる)
階層数下げるメリットも分からない。
Yiiはオートローダーを実現するためにこんなコードが200行以上も続くが、こんなんよりよっぽどマシだと思う。
private static $_coreClasses=array(
'CApplication' => '/base/CApplication.php',
'CApplicationComponent' => '/base/CApplicationComponent.php',
'CBehavior' => '/base/CBehavior.php',
'CComponent' => '/base/CComponent.php',
'CErrorEvent' => '/base/CErrorEvent.php',
'CErrorHandler' => '/base/CErrorHandler.php',
'CException' => '/base/CException.php',
'CExceptionEvent' => '/base/CExceptionEvent.php',
'CHttpException' => '/base/CHttpException.php',
'CModel' => '/base/CModel.php',
>>47 お前は何を言っているんだ?
Zendの命名が冗長だっていう指摘に対するレスなだけなんだが。
オートロードなんてクソ重くてコード保守性下がる物の為に、
コード規約を設計するなんて正気の沙汰とは思えないな・・・
あとYiiはオートローダを実現する為に書いているんじゃなくて、 オートローダのファイル検索オーバーヘッドを少なくするためじゃないの?w 200行程度、オートロード1〜2回行うより遙かに軽いよ。
>>48 出鱈目いうなよ。オートロードが速くて保守性がいいからPHP5のFWが使ってんだろが。
>>49 ファイル検索オーバーヘッドってなんだ?オートロードってファイルを「検索」してロードすんのか?w
>>49 spl_autoload_register(array('YiiBase','autoload'));
>>50 ベンチマークとって見ろよw autoloadって結構なリソース食うんだぜ。
最近のFWは機能こそ備えているけれど、デフォルトでは使ってないのもその為。
Zendとか、各クラスで使用するクラスをincludeしてるだろ?
生産性は上がるがクラス間の関係性が不透明になるから、保守性は下がる。
>ファイル検索オーバーヘッドってなんだ?オートロードってファイルを「検索」してロードすんのか?w
そうだよ?
インクルードパスに該当するファイルが無いか検索が発生するけど、これが想像以上に重いんだよ。
Yiiはその手間を省く為に、クラス名とファイル名のマッチングを使っている。
これはYiiな
それはautoloadを使う前提での require と require_once のベンチマークだろw Zend_Loaderのautoload経由でのincludeと、通常のincludeを比較してみろよ。 予め使うクラスが確定している場合はオートロードなんて使うもんじゃないよ。
autoloadするっていっても、一度に全てのファイルを読み込む訳じゃないだろうから、そこまで劇的に違いは出ないんじゃないの? autoloadを介す場合、 1.ファイルパスが書かれた設定を読み込み、配列にセットする。 2.ロード済みかチェックする 3.未ロードならincludeする という手順になると思う 速度に違いが出そうなところといえば、おそらく1.のパスを配列に詰め込むところでしょう。 数万ファイルあると、相当遅そうだけど、数百、数千ファイルのパスを詰め込むぐらいなら、それほど負荷はかからない様に思える。 また、この設定ファイル自体、更新頻度が低いだろうから、 アクセラレータを介したり、 初回は設定ファイルから読み込み→シリアライズしてしまえば、 さらに負荷を押さえられそうな気がする
「予め使うクラスが確定している場合は」 ワロタ。
Removing require_once in favour of __autoload shows one of the biggest performance improvements in my entire application - I shaved off roughly 220 milliseconds by removing about 15 (or so) calls to require_once in my bootstrap.php file. require_once is also the number one performance killer from the entire Zend_* code base. The before/after is amazing. Without any of those enhancements from the list just by stripping out require_once from our ZendFramework "install", we went from 9-10 requests/second to 27 requests/second. Zend_*コードから全てのrequire_onceを取り除き__autoloadに変えると 9-10 リクエスト/秒が27リクエスト/秒になった。
require_onceって何で遅いん?
>require_onceって何で遅いん? PHP側の読込み済みかどうかの判定がウンコだから
>>58 それって、フレームワークやライブラリ次第なんじゃないかなあ。
毎回、必要ないものを大量にrequire_onceしてるならautoloadしたほうが速いだろうけど、
そうでないならrequire_onceのほうが速いと思う。
その加減がわからんけど。
autoloadにしてエラーが出るおれには、死角は無かった。
>>62 >死角は無かった
資格はなかった、の間違いだな
>オートロードなんてクソ重くてコード保守性下がる物の為に、 >コード規約を設計するなんて正気の沙汰とは思えないな・・・ こいつが糞なのだけは分かった。
オートロードを推奨してる言語って何かあったっけ?
オートロードってモダンな言語では標準じゃないか?
そのモダンな言語を上げてくれよw 大抵はclassの頭にimportとかで明示的に使用するクラスを指定すると思うんだが・・・
言語によっては慣習的にライブラリを丸ごとimportするものもあるよね
だから具体的にその言語名を名前挙げてくれよ。 JavaとかC#みたいなコンパイラ型言語の事を指している? であれはコンパイル時にクラスチェックが行われるので、 PHPのオートロードで問題になる「実行時にクラスが参照出来ない」「どのクラスを参照しているか不透明」という問題は起こらない。 あと、丸ごとライブラリをimportするような慣習は無い。
言語というよりモダンなフレームワークじゃないか? Rails なんて 200 くらいのライブラリを import するよね。
オートロードは用意されているが、使用はされていない気がする>モダンフレームワーク
>>69 コンパイラ言語であることと静的性格は全く関係ない。
Objective-CとはかインタプリタじゃないけどPHPなんかよりもずっと動的性が高いし、
ライブラリを丸ごとimportする習慣もある。
>>72 丸ごとimportって、結局はコンパイラがコード解析及び妥当性をチェックして必要なクラスのみを取り込んでるんだよね?
PHPの実行時オートロードとは性質が異なると思うんだけど。
いや、存在する全てのクラスをランタイムに読み込むけど
皆はさ、一応フレームワークはcake、zendなど一通りやったの? それともcakeならcakeだけ?
symfony,code igniter,ethna,zend,cakeあたりは触ってみた
>>77 AppleとかAdobeとか絡む奴はみんなそんなもんだよ。
>>77 C#とかもimportしなくてもランタイムには全部読み込まれるだろ
明示的に全パッケージをimportするのと、実行時のオートロードは別物だと思うんだが。
phpのプロパティー名って hoge_hoge形式がいいの hogeHoge形式がいいの
82 :
nobodyさん :2009/10/16(金) 20:04:57 ID:QRRFB99x
hoge☆hoge
>>81 混在しすぎでどっちつかずだと思う
全体的にアンダースコア使ってるものが多いっちゃ多いけど
自作メソッドとかそういうのは好きなほうで統一すればいいんじゃね
hoge・F・hoge
ローカル変数はhoge_hogeだよね
Tsunoda☆Hiro
せい☆ぞん
ZE☆ND
アンダーバーとSQLとの相性は面倒
まずは自分で比較レポート上げろやミーハー野郎。
Zend PHP Store閉店でPHP脂肪www
Zen Cartはどうなるの?
>>91 Scalaに移る前にPHPのシンタックスをScala風にするやつ試してレポしてよ
97 :
nobodyさん :2009/10/28(水) 05:48:04 ID:wgov9hiD
>>96 プロモーション丸出しの記事でワロタw
ソフバン問題で一般にもあくどさがばれたから慌ててイメージアップ戦術打ったんだな
てかF氏は技術者としては悪くはないけど少なくとも神ではねえよw
何より本人が一番分かってるだろうけど
褒め殺しかよw
98 :
nobodyさん :2009/11/07(土) 10:30:17 ID:6jU57Qso
もう許してやれよ
>>98 香ばしくて痛いなw
勤めてる社名まで出しちゃって・・・若いって怖い。
101 :
nobodyさん :2009/11/08(日) 01:06:50 ID:35LWJ8zb
フレームワークに手を出そうかなと思ったのですけど どんなのを使っていいかわからない状態です とりあえず作る予定のサイトは テンプレートの共通点は多いけど、ページによって使うテンプレートの種類や個数が全然違う感じなんですけど、 よく分からないので、面倒なことを考えずに組み立てれば動くってくらい 初心者が取っつきやすいフレームワークを教えてください
Smarty
迷うくらいなら別にいらないのでは?
104 :
101 :2009/11/08(日) 01:43:45 ID:???
ですよね 確かにやりたいことはsmartyの方がやりやすいんですよね じゃあ 自分好みのフレームワークでも自作してみようかな ちいたんとsymfonyあたりをベースにほしい部分をコピペしながらでも
>>104 >ちいたんとsymfonyあたりをベースにほしい部分をコピペしながらでも
それがいいと思うよ
メモリリークが尋常じゃないってマジ? foreachの途中でreturnしたらメモリリークするってバグが5.0くらいの時にあったけど 未だに漏れまくりなのか?
でもまぁループの途中でreturnするのって プログラム的に行儀よくないよね 一つのところから入って一つのところから出るのがお作法ってもん
最後まで読んだら未確認情報かよw 適当なこと書いてんじゃねーよ でもまじめさは好感持ったからぢんぽ舐めていいよ
まじめ?w 嫌いだから長所に目をつぶって、短所を叩いてるだけの糞ポストにしか読めないが。
>>107 配列の中から、条件を満たす要素を取り出すとき、
見つかったら、そこでbreak/returnしないの?
最後まで回し続けるの?
>>107 君は自分でルールを作ってるのはいいことだけど
世の中は広い(ry
>>110 breakはするに決ってるじゃんw
ルーチンの結果に対して一様に処理を追加する必要ができた時の担保として、
出口を一つにするように心がけるってこと
「これに処理追加することはまずないし、いいだろ」と思って手抜きした時に限って
フローが続くことになることはよくある
breakをswitch〜case 以外に使える事がなぜか知られてない事実
continue nはPHPにしかないというあまり知られていない事実
レベル指定だと・・・・
最低の機能だよな。
>>113 実装してしまった事があるけど、ひどく可読性を下げてしまった覚えがある。
動いてるからいいよね、ということで自分を納得させた。
レベル指定した方がキレイに書けるコードも実際あるから ruby,python涙目ww
多重ループ中で、ある程度複雑なロジックが絡んだ時とか。 PHPで書いたコードをrubyに移植しようとして 「なんでこんな簡単なことも出来ないんだ?」と思ったことがある
>>107 そういう風に習ったのか思い込んでるのか知らんけど
うちの中華コーダー連中は全員そろいもそろって無駄なフラグを作りまくって
ごちゃごちゃした糞コード生み出してるなぁ
フローチャートに沿って出口ひとつ、とかって話も聞いたりするけど
今時フローチャートなんて書くようなのは組み込みのなかに残存するごく一部の旧世代位じゃねーの?
あぁ、たしかにcontinue知らないときはフラグ立てまくってたなぁ
フラグが無駄だとしたら 元の設計が悪いんだろw
テーブルタグで装飾に懲りまくると・・・・
>>120 rubyにはcatch〜throwがあるので、
レベル指定break/coutinueというだっさい機能は必要ありません。
PHPのcontinueは例外処理中の機能じゃなくて ループを制御する命令だよ
それにPHPだって例外あるし
あぁ例外でループを抜けるってことか 例外を本来の「何かおかしなことが起こったことを騒ぎ立てる」機能以外で使うことがエレガントだとは 俺には思えないなぁ 名著コード・コンプリートでも、例外の良さはcatchしそこねた時に それが誰の目にも明らかになることで、 明示的にそうでなければならない場合以外に使うのはよろしくないって書いてるね
いや、continueはループ開始に戻るんだが・・・
例外でループ制御するくらいならgoto文の方が素直で遙かにマシだよね gotoがないことが許されるのは小学生まで
>>126 -
rubyのcatch〜throwは例外処理ではありませんが。
>>130 ダメ。ゼッタイ。
gotoは駆逐されるべきだ
例外でないとしても、例外的な解決法だよね>.catch..throw 本当にこれが分かりやすいと言えるのか? gotoの方が直観的で分かりやすいのではないだろうか
君にとってはそうかもね。
書き込み
ある程度の大きさのサイトを作ろうと思っているのですが、この場合、cakeよりもzendの方がいいのでしょうか?
ココ(
http://www.phppro.jp/article/framework/comparison.php )等を見ると、cakeよりはzendやsymfonyの方が良さそうだったのですが、
zendのサイトに行って色々と見ている内に、日本語対応がまだ今一つって感じがしました
symfonyは書店で本の数が少なく、また、パッと調べた感じなのですが、日本語対応している詳細なリファレンスサイトが見当たりらなかったです
どれを始めるか悩んでいるのですが、cakeとzendの構築出来るサイトの規模はどの位違うのでしょうか?
個人レベルで終わるようならばcakeは無理そうなのですが
>>137 正直、cakeとzendで構築できないレベルの規模になると、フレームワーク自体は
どれを選んでもそんなに差は出ないと思う。どうせどっかしらに手を入れるだろうし。
ということは、自分の(チームの)開発スタイルに合うものを探すのが吉。
>>137 「※ 評価は、2007年11月現在におけるものです。」
古すぎわろた
141 :
nobodyさん :2009/11/10(火) 01:12:42 ID:6KTwa1YJ
だがそれから状況がどれだけ変わったかというと・・・ 変わった!
www どう変わった?
2007年11月ってーと、まだ1.1のころかな?
規模って?
Python, Rubyのほうが危ないんじゃね
まぁPHP程度で動くモノを未開拓の言語にしよう、って人は当分出ないと思うけど PHPが食われるっていうよりは、立ち位置的にJavaとか.NETをカリカリするのを狙ってそう PythonRubyに至っては、現状で既に率先して使う利点なんてほとんどないしな…
cakeのdataってプロパティ名最悪だよな 大抵のプロパティがdataだろ
Googleがどんどん便利なツールを出してくるね。 Webプログラミングも楽になるといいな〜
混沌を加速するだけのような気がする。 特にjavascript
Ajaxも使いたいのですが、Zendは対応していない(?)ようなのですが、もしAjaxとかまで考えるとZendよりもCakeの方がいいのでしょうか?
何を持ってAjax対応なんだい?
"PHPのフレームワーク"ってなかなかピンと来にくいよね
>>152 jqueryあれば、どれでもええやん。
ヘルパーが欲しいの?
156 :
nobodyさん :2009/11/18(水) 13:57:27 ID:PgcaH+BL
>>151 HTML5の登場で、JavaScriptの役割も整理(縮小)されるでしょうか?
HTMLを拡張しまくって、PHPが不要になっちゃう日も来るかな?www
アハハwwwww
クライアントとサーバの区別もつかんのかw PHPerは本当にレベル低いやつ多いよなぁ・・・同じPHP使いとしては世知辛い。
>>157 jsが動くのはアクセスしたPC、phpやjavaが動くのはサーバー
みんながみんなjsバリバリのサイトがサクサク動くブラウジング環境だとおもうなよゴルア と言ってみる
Netscape Navigator の頃にはjavascriptがこんなに普遍的な技術になるとは思わなかった。 まあ確かにどんなブラウザーであっても色鮮やかなサイトが増えましたよ、本当に…
HTML5の普及なんて、IEがあんあんだから、かなり先だろ
君達、どのフレームワークでサイトを運営してるの?
僕はちいたん!
拙者は下衆ワークでござる
>>165 素のPHP 5.0
正直フレームワーク入れれば良かった_| ̄|○
やっぱ皆フレームワーク導入しているのだろうか? 例えば大手サイトなんか
Facebookはどうしてるんだろうね
ラボとか凄い
5.0ってフレームワーク以前にバージョンに問題あるだろ・・
PHP 5.3.3 って言えば良かったかい。
FWの導入云々はいいとして、最低限MVC切り分けは欲しいな。
ZendとCakeのどっちを始めようか迷っています どっちがいいでしょうか? 用途は中規模のサイトに使いたいです
なんだそのデジャブ感
このスレのサイクルまとめ(40レスで約1サイクル) ・CakeとZFどっちがいいのでしょうか。(質問するときはZFではなくZendと表記) ・大規模小規模云々 ・結局のところ差はねえよ ・言語闘争 ・Ajax使いたいんですがどうすれば良いんでしょうか ・クライアントとサーバの区別もつかんのか ・君たち何使ってるの? ・僕はちいたん、拙者は下衆ワーク ・PHPバージョン闘争 ・最初に戻る
CakeとZFのどっちがいいのでしょうか、という質問に混じれす ・フルスタックで全部入り、そのかわりガチガチな環境がいいか、 ・必要最低限のライブラリとコーディング規約をもとに自由度の高い設計・構築をしたいのか が最大の違いと思われ。 あと別に片方しか使えないわけではない
Yii
時代はLithiumだろ。すげーいいぜあれ
混ぜるな危険。 両方の思想が入り乱れて分け分からなくなるよ。
PHP 4.x ・Cake PHP PHP 5.1 ・Yii ・ZendFramework ・symfony PHP 5.3 ・Lithium
5.1とか…
CakeとZFを一緒に使うなって意味じゃね? MVCの切り分けはCake側に一任する前提で、 pearライブラリ的にZFを使えば共存できるとは思うが
Google App EngineでPHPのフレームワーク動かしている人いる?
190 :
nobodyさん :2009/12/05(土) 11:54:47 ID:djRTaKZ8
かなりくだらない話だけど dとかhみたいな関数を定義しているフレームワークって何でしたっけ?
rhaco?
CakePHPにもある
193 :
190 :2009/12/05(土) 18:17:16 ID:???
あれ いくつかのフレームワークで使われてたんですか ありがとうございました
194 :
nobodyさん :2009/12/06(日) 11:13:35 ID:CFjhkm3+
PHP4でMySQL5.0とConnectする場合にはOLDPasswordの設定が必要ですが、 OLDPasswordを設定しなくてもいいPHPのバージョンは、PHP5.0以上でしょうか?
OLDPasswordて何?
196 :
nobodyさん :2009/12/06(日) 13:10:13 ID:CFjhkm3+
Windowsなんてしらねーよw
S2とか付いてるとJavaぽいな
.php?とか出しちゃうのは論外だけど やっぱURIはそれだけである程度読み取れるような意味のある文字列にしたいとこだな IDとか連番ものはしょうがないけど
ださいかださくないかが判断基準になってるあたりまだまだだな
>.php?とか出しちゃうのは論外だけど なんで? どいつもこいつも、スマートURLに毒されてないか・・・?
ベタ打ちな感じのURLだろうが、きれいなURL()、だろうが PHPで作ってる以上動作の差なんてまず出ないんだし、 PHP()使う以上見た目くらいはまともにしたいわなぁ
スキルのないコーダー多いPHPerにそういう注文つけてやんなよww
短いほどいいとかPHP歴6ヶ月目くらいのプログラマにありがちだね
mod_rewiteの使えない環境とか環境とか考えないんだろうなw 個人的には拡張子は無い方がいいが、GETクエリはあってもいい。 むしろWEB標準としてはそうあるべきで、スマートURLなんて所詮SEO対策に過ぎない。 スマートURLにありがちな、パラメータなのかファイルなのかわからなくなるってのはメリットでありデメリットでもある。
いやスマートURLの方がいいだろ 今時パラメータをズラズラ並べるなんてケミカルウォッシュジーンズに素足革靴を合わせるぐらい時代遅れですよ
んな流行なんかねぇよw
ZendFrameworkって結構難しいね Zend_Controller_Frontの部分でいきなり「何だコレは?」と身構えた PEARとかのライブラリとか簡単だったから今回も楽かと思ったんだけど、次元が違いました・・・
パラメータを&でつなぐ変わりに、/でつなぐ。それがどうした?と言わざるを得ない。
ぼくはREST原理主義者なのでそれ以外の人は帰ってください
RESTは支持していいとおもう ?hoge=moge&hige=mageとかもうやりたくない
あ、1行目と2行目は特に関係はないです 全くないってわけじゃないけど
Cake難しいZendも難しい どこへいけばいいんだあ
Kohanaにどうぞ。
Yiiイイヨー
ちいタンハアハア
Yiiの劇速ベンチ
http://www.yiiframework.com/performance これみてビビったんだが、実際のアプリケーションでもこんなに変わるの?
それとも手前味噌なベンチマークなの?
一応phpmark projectとしてオープンにして透明性を維持してるみたいだけど、
Hello Worldアプリだったら、無駄なincludeを排除するYiiが圧倒的劇速になるのは当然か・・
Yii使いの人、ご意見ください。
ハローワールドでベンチ取ったり ハローワールドをどれだけ短いコードで書けるかで言語の優位性を示したりするのって 何か馬鹿みたいだよね
222 :
220 :2009/12/12(土) 20:42:08 ID:???
>>221 正直僕もそう思うんですが、
実際問題、Yiiは実際のアプリで速いのかどうか?
を知ってる人がいればと思って書き込みました。
まあ、「実際のアプリ」って何やねんって話になるんだろうけど、
・条件に合ったものをソートして一覧表示
とか、
・あるレコードの詳細と関連するモデルのレコードの一覧表示
とか、
・テキストフィールドから入力->入力値バリデーションをパスしてレコード追加
とかそういうのになるのかな
結局dbのパフォーマンスが構成要素の多くを占めることになりそうだな
>>221 馬鹿はお前。そのページのWhy "Hello World"を読めよ。
>>222 >結局dbのパフォーマンス
それならAPCとか要らないよ。
データベースサーバをチューニングするのは、アプリケーションサーバとは別の話だから名。 KVSなんかの利用でDBがボトルネックにならない状況が成り立つ事もある。 PHPが流行った理由の一つが、Perl/CGIより高速な事だから名。RoRが普及しないのもCGIじゃ使い物にならないからっていうのもあるはず。 Yiiって全然知らないけど、Rasmusは関係してるんだろうか。あの人、昔からPHPのウェブフレームワークに否定的だった。
そんなにハローワールドが好きなら 生PHPの <?php echo 'Hello World'; も並べとけや
あ、Yってあるから、Yahoo絡みかと思ったら、全然関係ないんだな。
YiiがAPCの効果をフルに(7倍以上で)享受しているのはどうしてなんだ APCナシの状態では他よりちょっと速い程度なのに ちなみに、手元のcakeの実アプリ (ゲスト使用/ログイン使用で権限が変わる、ある実稼働サイトのソースコード)で apc on/offでabベンチとったら3倍弱程度のRequest Per Secondsで、 ちょうど件のYiiのベンチにあるcakeの項目と同じ程度のAPCキャッシュ効果だった (モデルキャッシュをFileでなくAPC側に持たせることでちょびっとだけ数字が改善した)
俺俺FW用意してない自分にとっては簡単なWebアプリとか作るとき > yiic shell > model HogeTable > crud HogeTable が便利だとおもった
>>226 そんなに生PHPが好きならこのスレ来るなよ
そうかそれは悪かった、すまん事した。
>>226 phpタグが閉じられてないのが気になる
これがファイルの中身全てなら閉じないだろ普通 下手に閉じた後に空行があると、その、なんだ、困る
なにそれきもちわるい
ちょっと終了タグ消してくる
今時のコードは大体入ってない
むしろ閉じタグは最近見てないな <span class="hoge"><?php echo moge ?></span>みたいなのもさすがに書かないし
mogeは定数か?あーん?
>>239 ビューテンプレートに生PHPを使うときはしょうがなくね?
何かのテンプレートエンジン使ってるの?
まぁタグ吐くだけならDOM作らせりゃ良いしHTML自体書く必要は別にないわなぁ ちゃんと属性なりふってあんならレイアウトなりはCSSいじりゃ大抵はなんとかなるし 似非デザイナー()笑とかがいるようなのだとHTMLテンプレとかないとアレなんだろうけど、 趣味でやるなら全部PHPでやっちゃうのも別に問題ないとは思う 半端にHTMLタグ混ぜて>><><みたいなのがいっぱいになるよりは幾分は綺麗に見える気もするし まったく逆方向で、マークアップすんだけのHTMLのインデントに 命かけてるようなひともいるわけだし、そこらは好き好きだろうけどw
243 :
241 :2009/12/15(火) 23:59:56 ID:???
なるほど。参考になります。 ただ実際問題、有償案件であれば、見た目に関わる部分はデザイナーなりコーダーかました方が、見てくれはいいわけで、 そこも自分でやっちまう or デザインは2の次 or コーダーさんがvalidなものを書ける なプロジェクトならばDOM生成でも良いわけだが・・・ つかここフレームワークのスレだな
Yii使っている人に質問っす。 みなさんは1.0.xつかってますか?それとも1.1を使ってますか?
使ってる人じゃないけど。
それなりにあちこち変わってるし、どっちの情報も大して出回ってないし(国内とか数える程)、
いまから触るなら1.1系でいいんじゃないかな。
>>243 なんちゃってデザイナーがTableレイアウトしまくったりする現実を見てると
肩書きがWebデザイナーってても信用しづらいけどねw
ちゃんと理解して使えるなら誰がやっても良いとは思う。
文章なんかの意味づけだけならコード上で済ませてもいいんじゃないかな。
速度云々が気になるような差になるようなとこでもないし、
自分的には半端にHTMLとPHPコードが混ざってるのをぐいぐりするよりは好きかも。
まぁ確かにFWと関係ないけど、このスレではよくあること…
PHPでそれなりに使えるマって HTML触っててその延長で覚えたりしてる人とか結構いそうだし、 いい加減な性格じゃなけりゃXHTMLやらCSSやらいは勉強してるとは思う まぁ問題があるとすれば全体的に使えないマのほうが多いってことだけどw
247 :
nobodyさん :2009/12/16(水) 11:04:38 ID:KzRQDWcs
ZendFramework使ってます。 ビューのhtmlをパーツ化してて、ほとんどのコントローラで最終的に呼ばれるものがあります。 例えばページのメニュー表示の部分とか(ビュー内で、共通のhtmlをrequireしてます) 共通のhtmlの中身が今は完全にべた書きになっていて、これをDBから取得した値に動的にしたいんだけど これって全部のアクションコントローラのコンストラクタ内にDB取得の処理入れなくちゃいけないものですか? もしくはそれぞれアクションの中にとか。。 ただ、共通のhtmlが読み込まれない場合もあるので コントローラ内で必ずDB取得しにいくってのも無駄だなぁって思ってます。 これは共通のhtmlが読み込まれた時だけ、ajaxで取得しにいくようにしといたほうがスマートですか? なんかフレームワーク使ってなければ、必要なページでメニュー表示用のphpを読み込むだけで済むのにって思いました。 フレームワーク使うと、ビュー側でどうされてもいいように、コントローラ側で全対応しとかなきゃいけないものなんでしょうか? 自分がフレームワークをよく理解してないせいですかね。。
マルチ乙
249 :
241 :2009/12/16(水) 16:51:36 ID:???
ほんとだマルチだ しかもどっちのスレもスレ違いだしw というわけで該当スレに行ってきましょう
F/Wがどうとかいう話じゃないな。設計の問題
>245 1.1で行ってみます。 しかしまあ、仕様がシンプルなので、使うの楽ですね>Yii
Yiiって任天堂が商標取ってるらしいから そのうち改名しそう
カテゴリーが違ったら商標は別扱いになるし Yiiの名前はYii Frameworkだから平気。
じゃあファミコンFrameworkでも問題ないん
Wii Framework PS3
>256 いつの間にか、日本語訳されている箇所が増えている!!! 中の人、お疲れ様です。
最近YiiDocと待ってるんだよな 英語さっぱりなので手伝えることはないけど新しいとこの翻訳がずっと手付かず
>>253 お前、小・中学校時代クラスで一番下だったろ
日本の失業率は5%(総務省統計局・労働力調査)だ
5%って事は20人に1人、1クラスが男女半数ずつ40人として
クラスの男1人は無職になるということだ
お前、クラスで一番下じゃなかったか?
テストの点数なんか聞いてないぞ。人間としてだ
よく思い出してみろ。無職になるのは、誰だ?
>>259 そんな誤爆してぇ
> お前、小・中学校時代クラスで一番下だったろ
>>259 > 1クラスが男女半数ずつ40人として
歳がばれるからやめとけ。いい歳して。
1クラス40人だと30代後半以上の歳か? 今時は、30人くらい?
で、昨今の学力低下を見るに、日教組の連中が行ってた 一クラスの人数がもっと少なければ、もっと密な指導が〜 は、全くの嘘だったと判る。 と、スレ違いをさらに引っ張ってみる。
だな。教員の数を確保するための詭弁 40人中でトップを争うか30人中で争うか、その違い。 どのみち社会をリードするのはトップの連中なのに、 リーダー格が育たない原因を作ってるからな。 今の日本じゃみんな井の中の蛙化してプライドだけが高い
クラスの人数が少なくなった上で学力的な成果が出てしまうと困る奴がいるんだってさ
>クラスの人数が少なくなった上で学力的な成果が出てしまうと困る奴がいるんだってさ 意味分かんねぇよw
そういう意味じゃないのw
スレタイと関係無いので皆様起動修正しましょう
takerunbaってFWはどうよ 日本人が作ったらしい
名前からして、ちぃたんと同じ匂いが
今までFWを使わずにやっていましたが、ZendFrameworkを学習しているのですが色々とめんどくさくなってきました PEAR、Smartyは結構使えるのですが、CakePHPは併用は出来るのでしょうか? 名前空間がしっかり出来ていないとかいう指摘は聞きますが・・・ ZFはPEARのようなライブラリっぽくて使いやすいかなとか思ったのですがPHP関数で非推奨なものとかあったり、せっかくPEARで覚えたものと重複していたりで無駄に思えたりでCakePHPにしようかなと思っています ZFはいいFWだとは思うのですが マニュアルを見たところ、ZFに比べると記述量も関数も非常に少なく思いましたが、その分CakePHPは今までの自分の持っているスキル(PHP、PEAR、Smarty等)をZFよりも反映させやすいのでしょうか?
PHPの次の十年のためのフレームワークBlankaの話
ttp://d.hatena.ne.jp/anatoo/20100116/1263620509 > タイトルはここからインスパイアされた。
> 最近PHP5.3で動く新しいウェブアプリケーションフレームワーク作っている。
> まだ一度もリリースしていないが以下その概要について箇条書きとサンプルコードを少し書く。
> * PHP5.3以上で動く
> * コントローラ = コールバック
> * コントローラを作るのに必ずしもクラスを書く必要がなく、匿名関数でもよい
>>273 のページで
Blanka::app(new MyContainer)->respond(Dispatcher::it()
->{'GET /user/{name}'}('@page¥User')
->{'GET /'}('@page¥Root')
);
というサンプルコードが載っているんですが、「->{'GET /'}」というのがよくわかりません。
PHPでこんな文法って許されるんでしたっけ?
ただのメソッドチェーンでしょ。Hoge()->Fuga()->Moge()と同じ
タケルンバフレームワークいいね シルクハットの人goodjob
宣伝するならURLも張っておけばいいんじゃないの
ZendFrameworkって難しくない? 本とマニュアルで学習してるんだけど、全然進まない・・・ 構造難しいし、メソッドとか新しく覚えなきゃいけないし、それにマニュアルがいまいちで関数調べるのにめっちゃ時間かかる
>>278 簡単で親切なFrameworkを使えばいいんじゃね?
何と比較して難しいって言ってるの?
>>279 いや、比較してってわけじゃなくて、ZFそのものが
まだ情報が少ないのか、Webで分からないところを検索してもあんま出てこなかったりするし
かと言ってマニュアル読んでも分からなかったり
ZFはリファレンスマニュアルがいまいちというか読み辛い 本は物によるだろうけど、自分が買った奴はわかりやすかった
中級者くらいじゃないと使いこなせないんじゃないかね 難しいと感じるなら先にPHPの能力を鍛えたほうがいいかも
ZFは最初のMVCが難しいからな 構造が入り組んでたり、PHPの学習では出てこないような単語とか出てくるから
yiiのyiicツールのcrud コマンドでコントローラーを生成したとき actionIndex()のコードの頭に”0”が付くのは仕様? 0 public function actionIndex()
どんな仕様だよ。 気のせいじゃね?
>>286 自己レス
yii\framework\cli\views\shell\crud\controller.php
line 127|| 0 public function actionIndex()
となってるからshellで”0“が入るのは仕様みたいだ。
おお、yii 1.1 Stableになったのかー 1.1.0 (January 10, 2010)落としてきてみたが 127|| public function actionIndex() まさかとは思うけど自分でいじってて0書き込んだりなんてアホなことしてないよね? 更新日時とか、変わってたりしないよね?
289 :
284 :2010/01/21(木) 21:15:45 ID:???
>>288 >更新日時とか、変わってたりしないよね?
変わってた…orz
これは天狗の仕業か!?
アホなことでお騒がせしてすいません。
さすがにリリースされてから10日以上たってるのに、 そんなあからさまなバグ含めたままリリースしてるわけないとおもうのw 参考にコード見てて間違えてキー押しちゃってたりすることは稀に良くあるしな
メーリングリストより
【xFrameworkPX 3.5】
ttp://www.xframeworkpx.com/ でもアクセスすると
Fatal error: Maximum execution time of 60 seconds exceeded in Unknown on line 0
というエラーが。これはまずいだろう。
おまえらSmarty3が出るみたいだけど、どうよ?
PHPのプログラムをwindowsで実行するにはどうすればいいですか?
コマンドプロンプトで php ファイル名
>>292 今ので不都合無いし、様子見
2年後くらいなら使えるようになるかねぇ
あえて仕事増やす必要ないよな
smarty3はマジ地雷。 2をまともに進化させてほしかったな。 3は、初めて書いたプログラムを、ひと月後くらいにちょっとわかった気になって綺麗に書き直そうとしたら、下手な知識が仇になって余計悪くなったみたいな感じ。
具体的にどんなところが?
>>300 タケルンバが作ったのは信頼性低いな
できれば避けたい
仕事でPHPのプログラミングしてる人はたいていフレームワークを使ってるの?
時と場合による
>>302 だいたいタケルンバかcake使う
生はここ半年ほとんど無いな
タケルンバで代用きくし
タケルンバってなに?キモい
アンチタケルンバ乙
タケルンバか、もしくはphaのどちらかで迷ってる
どのフレームワークを使うかはリーダーが決めるの?
だからタケルンバって何だよ
ちいたんは名前とかでまだネタにできたけど
そのタケなんとかってオナニーFWと予想されるゴミおそうとすんのは作者くらいだろw
誰も触ったことなんてないから説明のしようもないし、今後触ることもない
記憶にとどめる意味もないと思われ
多くはこれ
>>2 のどれかで、業務でつかってるの大半はCakeだと思われ
あとここにないものだと、興味からYiiを触ったりする人もいるみたいかな
もっとも、小規模のものは生PHPでFWは使わない(使うスキルがないとも言えそうだが)
人の文句しか言えない方はかわいそうですね タケルンバさんはそんな風に匿名で人を貶めることはしませんよ
本人乙w
誰のことか知らんが自分のサイトでやってくれ
タケルンバについてkwsk (俺は)宣伝乙とか言わないのでとりあえずURL貼ってくれ 俺以外の奴が宣伝乙って書くだろうけど で、さっさとこの話題きりあげようぜ
フレームワーク総合スレなんだから、phpのフレームワークに関する情報なら歓迎
誰だよw いや知りたくもねーよw
>>315 同意
フレームワークについて知りたくないなら来るなっつーの
タケルンバうぜー 最近2chのあちこちで見かける どうせクソブロガーの宣伝っしょ
名前張ってるのはむしろアンチなんじゃないかと思うぜ
Cakeってどうやって覚えたらいいの?
商用じゃねーし俺はYiiを使ってみることにしたよ。新しいもの好きなんでなんか興味わいた
>320 生PHPがある程度できるなら、ガイドブック買って流してみるってのが王道かもなー
ネタでやってるなら空気嫁 私怨があるなら他所でやれ単純に迷惑 宣伝したいならもっと別のまともな手で魅力を訴えて見せろ
こりゃ、むずかしい。
>>326 これが難しいと思うならCake入門本かPHP入門本で簡単なWEBアプリを作ったほうがいいかも。
$userがキモい
cakeの良い入門書が見つからない
だからウェブのチュートリアルとマニュアルが一番だとあれほど(ry
こりゃ、むずかしい。
フレームワークってセキュリティはどうなんでしょか? PHPでやっているようなセキュリティを自分で記述していく必要があるのでしょうか? それともフレームワークの方である程度行ってくれるのでしょうか? また、フレームワークを使ったからこそ起こった、というようなセキュリティホールなど存在するのでしょうか?
生でやるのとゴムつけるのの違い程度には安全なんじゃないの?
つけたら快適なサービスが得られないと
>>335 結構上手い表現だと思うがw
使ったら使ったで注意点があるしな。
慢心してると大穴あったりする。
340 :
nobodyさん :2010/02/28(日) 10:29:01 ID:xRtiCHYH
rhacoって簡単そうだけどドキュメントが無いのが痛い・・ 使ってる人います?
話題にもならないから、ほとんどいないと思われ
342 :
sage :2010/03/03(水) 13:48:57 ID:bgcdMcjm
340です やっぱそうなんですね、レンタルサーバーとかでも使いやすそうで、 ライブラリとしても使えるとのことでしたので もう少しかじってみます。
初心者?向けな気がする 今後もfw学習していくなら触れない方がためな気もする・・・
CakePHPから派生したLithium CodeIgniterから派生したKohana ここらもチェックしてみてはいかがでしょうか?
今のところ国内ではcakeが強いの?PHP事情に詳しくないんで教えてくだされ
symfony じゃね
でも個人ブログなんかで取り上げられるのはcakeが多い気がする 実際のところシェアってどうなってるんだろ
サイトの数と、そのサイトが稼ぐPVをスコアとすると、シェア変わりそう
zend一択
何を使うかより何を作るかが重要
ド正論で仰るとおりだと思いますが、方法論や手法について語るスレでそんなことを仰られても困ります
>>352 それは多分、PHPという名のケー(ry
Lithiumに期待せざるを得ない
タケルンバはLithiumに興味ないの?
やっぱりcake
タケルンバに期待せざるを得ない
cake難しいよな。コード読めない。 Zend難しいって言ってる人は、コード読む気がないんじゃなかろうか。 あれだけ素直に使えるライブラリは素敵だぞほんと。 $this->Posts->set($this->data) いきなりこんなの理解できるか > Cake $this->dataには何が入ってるんだよ > Cake んで、どうやって応用すればいいんだよ > Cake $this->hoge = "page" これはどこに何をセットしたんだよ。 > Cake 以上、私怨スマソ
まず名前がダサい。そんなもの使うくらいならまだちいたん選ぶわ
いや景気の良いネーミングだと思う
>>360 ちいたん(笑)
まずは自分のセンスを疑えよ・・・
これから学ぶならlithiumだろー
CakePHPもMojaviのような運命を辿るのか。
PHP4対応を捨てたCakePHP、ってだけでいいんだけどな Lithiumって、なんかいろいろ頑張って、結局完成とか安定とかしないイメージ
理想を追いかけて遠い存在になるより こまめにアップデートしてくれるほうがいいんだよね
>>366 両方必要だけど自分が使うならやっぱ後者だなあ。
でもこまめにアップデートされても、そう簡単にシステム更新できないからなー
Cakeは1.0以前、1.1、1.2あたりまででかなりいろいろ変わってきてて、 1.2->1.3の変化量は、それまでのちゃぶ台ひっくり返し的な変化に比べればそれほどではないと思う。 つまりなにがいいたいかっていうと、内部の激変はそれほどこないんじゃないかな それがいい事なのか、それともmojavi化(停滞・gdgd)なのかは知らん というか、ずっとPHPのフレームワーク周りを追っかけてきてて、むしろPHPに固執する必要があるのか? という事も考えてしまう。 そんな俺がPHPベースのFWでこれからどうなるんだろうとwktkできるのはYii
<[include:header.html]> <[if:$a==1]>hoge <[else:]>hage <[end:]> みたいなソースってなに? フレームワークなのかどうかもよくわからない php初心者ですが、えらい人教えてくらさい。
>>370 それ、テンプレートってどのフレームワークで採用してるの?
>>371 ??どのフレームワークかを知りたいのですが、、、
すんません全然フレームワークもテンプレート?も
理解してないので会話になってないのかな。
ディレクトリのどっかみたらわかる?
>>372 めんどくせーから単刀直入に聞くけど、そのソースどこから拾った?
>>373 拾ってない
外注したうちの会社で使ってるのウェブベースのソフト
つくったソフト会社とはわけあってほとんど会えないし、
こっちでいじるの嫌がるので(当たり前だね)聞きづらい。
>>370 の情報だけで特定出来る対象を、少なくとも俺は知らない。
たとえば外注の自作フレームワークならここで聞いても答えようが無いわけで。
そのファイルを読み込んでいるプログラムがわかれば判断できるんでないの。
そっかあれだけじゃ判断できないのか。 自作かな ともかくありがと
>>376 特徴的なので、あれだけでわかる。
elseの後の:とか。
だが、誰も知らないので自作だと思う。
ちょっとpythonっぽいテンプレートエンジンだな ほんとにこのスレの守備範囲なのかどうかも微妙
>>369 Yii良いです。シャレじゃなくて。
でも専用スレが無いのね。
>専用スレが無い そうなのか。この時点で辛いなw 頑張って流行らせてくれ。そしたら使うしノウハウも共有できるから
ヤフーに見えるのが良くない。
言われるまで考えたこともなかった
yiiのチュートリアル動画でヒーハー!いうやつがウザくて使うのやめた
今見てきた。ヒーハー大杉で泣きそうになった
ヒーハーは大杉より小杉
誰が馬
吉田「どうかしてるぜ!」
何だっけ、「コンポーネント指向」の奴だっけ > Yii あのフレームワーク使って、どの辺がどう「コンポーネント指向」なのか まったくわからん、ってのが最大の敗因かと思う。
敗因って別に負けてはねーんじゃね ただ新しく覚えるのがめんどくさい層は手を出さないから利用者増えてないってだけで
勝ってないからその原因を敗因と言っ(ry
まあ勝負の土台にあがってるのかどうかさえ不明 でもパフォーマンスの高さは気になる
新しく始めるならアリだとおもうよ。使い勝手は悪くない
Yii1.1.1のCRUDコマンドで生成したビューは結構完成度が高い。
Yiiって日本語ドキュメントできてるのね。ちょっと試してみよ。
crudで作ったコードは1行コメントアウトしないとレコード入らない
日本語化活動してた人たちも殆ど音沙汰なしな感なのが(´・ω・`)ションボリ
おk そろそろ期待の新星、symfonyの話でもしようか。Propelいいんじゃね?
釣り乙
symfonyってもうダメなの?
symfonyで作られたサイトって今どれくらいあるんだろう?
そんなにあるのか
もうちょっとあるよ
IE8のでふぉHTTP_ACCEPT_LANGUAGEがjaからja-JPにかわって 言語追加しておかないと、Yiiのrequirementsで日本語表示されないのう サブコードついてたらそれに見合うディレクトリがある前提で見に行っちゃうし きちゃないけど、こんな感じの追加とかしたほうがいいんじゃないかのう requirements/index.php 224| if(!is_file($viewFile)) 225| $viewFile=dirname(__FILE__).'/views/index.php'; 224| if(!is_file($viewFile)) 225| { 226| list($lang)=explode('_',$lang); 227| $viewFile=dirname(__FILE__)."/views/$lang/index.php"; 228| if(!is_file($viewFile)) 229| $viewFile=dirname(__FILE__).'/views/index.php'; 230| }
>>405 それ尼じゃなくて、出版元のebook(印刷可)で予約したら
14.44GBPだから約半額で買えるぞ。てか予約したし。
決済時にGBPが暴騰する可能性が
現金で払ったのか?
paypal→カード→円転
カードってカード会社の精算日のレートであって決済日のレートじゃないんだよな
1ヶ月後・・
>>407 「まだ届かないんですが。」
PHPでDIコンテナを使う利点が説明された資料があれば教えてください。 DIコンテナをPHPで使う利点がいまいちわかりません。 勉強したいので、「わからないなら使わなくていい」という回答はご遠慮ください。
資料も何も概念調べて自分が受け持ってるプロジェクトに当てはめて検討するだけだろ 1分で理解出来る概念に資料も糞もないわ
遠慮はいらん
DIを理解してないのであれば、まずは理解してください 理解さえできれば、メリット、デメリットはすぐに見えてくるかと思います 勉強のとっかかりかたまで教えてもらう必要があるように程度が低いのであれば、諦めるというのも一つの手です ってか、ド素人なにわかな俺でもぐぐって3分かからずわかるような内容じゃん… そもそもこれ別にPHPでって言語で限定するような内容でもないよ PHPの使い方はこうあるべきだ!なんて思ってる人なら色々思うところあるんだろうけど 勉強したいなら勉強しましょう。質問したいならどういう理由で利点がないと感じたかを書くべき
依存性の注入とか言われたってわからんわい、って別におかしくない 「3分かからずわかる」はないわ あと、コンパイルしてデプロイして云々のJavaでのメリットはわかりやすくても、 それをPHPに持ち込むメリットは、正直具体例をあげて誰かに説明してもらいたい
難しいこと言ってるけど classのラッパーを作成するってだけのことでしょ
>>420 そりゃあんたがセンスないからじゃないの?
今までにまともな設計した事ないでしょ?
>>419 >そもそもこれ別にPHPでって言語で限定するような内容でもないよ
これは多言語を理解していないか、DI自体を理解していないな。
>>417 >1分で理解出来る概念に資料も糞もないわ
大変優秀な方ですね。私にはとても1分では理解できませんでした。
DIコンテナは、Javaではよく使われてますが、動的な言語ではほとんど使われていません。
PHPのような動的な言語にもDIコンテナが役立つかどうかについては、いまだ結論は出てないようにおもいます。
ただ、PHPにはDIコンテナをうりにしたフレームワークがあるようなので、動的な言語でもDIはこんなに便利だと
いうのをうまく説明できる人がいらゃっしゃることを期待して質問しました。
ですので、なにか情報をご存知の方がいましたら教えてください。
そもそもJavaでDIを使う事のメリットは理解してるの?
依存するクラスに変更があった場合でも元のプログラムをmakeする必要がない
いや違うと思うが
働いたらmakeかと思っている
昨今のマならもっと概念的なとこで考えれよ
理解できたらあとは
>>417 。ケースバイケースだって意味がわかってくるんじゃないの?
>>426 みたいな人には、「わからないなら使わなくていい」、という回答以外にいい答えないと思うけどな
//そもそも割とスレチ
//PHPのフレームワークにそういうのがあるから、っていっても
//そのフレームワークの話題どころか名前すら出してないのに、わざわざこのスレで語る内容かこれ
//
DIコンテナってclassのラッパーのことだろ 言葉は知らなくても自然とやっている人は多い
>>DIコンテナってclassのラッパー こいつは全然わかってないのは分かった。
それはデザパタのAdapterパターンだと思うの…
職場の習慣で使ってはいるが 便利さはわかってない
まずはDIコンテナの前にDIを理解しよう。 DIはソフトウエアパターン、DIコンテナはそれを実現する技術の一つ。
今度久々にPHPの開発をするようになった。 どうせならフレームワークを使いたいと思うので 皆さんのお勧めを教えて下さい。 要件ですが 業務システム DB MSSQL 2005 テーブルは既存システムのを使うため変更出来ません OS Win2008 std 64bit 更新系ほとんど無し 参照系7本 単純な認証あり 複雑なSqlを書ける必要あり グリッドでドリルダウンをしたいのでajaxを使うかも。 言語は、主に英語 MSSQLのストアドプロシージャも 使うかも。 設置が簡単であって欲しい。 javaやc#でseasarを使ってるので 使えたらDtoを挟みたい。 よろしくお願いします。
流れきって悪いけど yiiでinput要素を順次saveしていきたいんだ。 そこでrecordをまとめた要素をforeachで回して saveするため、 $model->attributes=$data['post']; $model->save(); $model->refresh(); としているのだがprimaryIdが更新されないために レコードがupdateされて結局最後のレコードしか保存されない。 yii使い始めたばかりなんだが正しいやり方を知っていたら教えてほしい。
>>439 自己解決しました。
とりあえずprimaryIdが新規とされるようメンバ変数を修正したが
ちょっと無理やりっぽい。
あまり例が無いからどういった処理が正しいのかわからないな。
saveAllがあると良いんだけど。
そもそもDIコンテナ自体がフレームワークなのでは
yiidocはとまったままなのかのう 翻訳が進んでないのが悲しい。英語苦手だから助かってたのに
DIコンテナは静的型付け言語だから必要といってもいいものだよ。 型の依存、たとえばこのクラスAは、クラスBを継承しているなんてものがコンパイル時に決まってしまう。 そうすると単体テストがやりにくくなってしまう。たとえばクラスAのテストをするとき、 クラスBは無いものとして行うのが単体テストだから依存性があるとテストしにくいわけ。 これを取り除いて、クラスAはクラスAとして、クラスBはクラスBとして 独立している状態で実行時に設定ファイルにより継承関係をあとから付け足すのが 依存性の注入。 PHPなどの動的型付け言語の場合、evalなどの機能で実行時に クラスとか関数を作れるので、DIコンテナのような仕組みが無くても 言語仕様の範囲である程度は作れてしまえる。 静的型付け言語だとそれが難しいから、DIコンテナのような仕組みを 作らないといけない。まあ一種のフレームワークだね。
「静的型付け言語だから〜」 よくある誤解だ。もし動的言語でDIが全く不要なものならSymfony2.0で採用されないだろう。 再コンパイルが不要というのはDIの効果のごく一部に過ぎない。 「設定ファイルにより継承関係をあとから付け足す」 これも従来の特定のDIコンテナの一部実装に過ぎない。Guiceだと非設定ファイルでの注入が普通だ。
結局理解できてない人の暴走だったっていうオチ
>>444 結局DIコンテナの有用性を一つも指摘してないじゃないかw
三行で説明できないものは普及しない。これは歴史的事実。
どんなものでも 三行で説明できます。 ただし一行の文字数は無制限という前提で。
非常識だ
>>428 >
http://www.slideshare.net/fabpot/dependency-injection-with-php-53 >これみたらわかると思うよ。
ありがとうございます。まさにこういう資料を探してました。感謝です。
これを読んで、自分なりには以下のように解釈しました。
・DIはdecouplingが目的である
・decouplingすることはPHPのような動的言語でも役に立つ
・ゆえにPHPでもDIは役に立つ
#間違いがあればご指摘ください。
この資料のおかげで、自分なりの結論が出ました。ありがとうございます。
>>436 >DIはソフトウエアパターン、DIコンテナはそれを実現する技術の一つ。
まさしくそのとおりですね。DIコンテナを使わなくてもDIは実現できますが、
DIコンテナを導入した方が自然に記述できると思ったら導入すればいい。
>>437 こちらもありがとうございます。実装が240行程度なので、参考になります。
>>444 >もし動的言語でDIが全く不要なものならSymfony2.0で採用されないだろう。
ですね。その点、RubyやPythonのフレームワークより、PHPのほうが一歩進んでいるという印象を受けました。
レスくれたみなさん、ありがとうございました。>430みたいな人ばっかりだったらどうしようと思いましたが、聞いてよかったです。
まあ全部俺なんだがそれなりに分かったようで良かったよ。 DIはとかくいろんな事がごっちゃに語られやすい(=初学者に本質がわかりにくい) スライドの11/104が最も単純な依存性の注入。メリットは25-33にまとまってる。英語がわからなくてもコードでわかるだろう。
>>451 なんと全部同一人物とは。
PHPにもこんな賢い人がいるじゃないですか。
名前は存じませんが今後ともご活躍を祈っております。
そんなにとくべつ賢い発言にも見えないけど
普通にバカにされてるように見えるが
スレチ失礼。ATNDより、PHP関連の勉強会を紹介します。
■Ktai Library for cakephp 勉強会@関東
URL:
http://atnd.org/events/6209 日時: 2010/07/17 11:00 to 15:00
場所: マイ・スペース&ビジネスブース池袋西武横店
参加条件: Masa-Pさんの本「PHPで作る携帯サイト デベロッパーズガイド」を持参、かつ4章までを自力である程度実装できている、もしくは出来る方
■OpenPNE3で学ぶsymfony勉強会
URL:
http://atnd.org/events/6255 日時: 2010/07/24 15:00 to 17:00
場所: 手嶋屋新宿御苑オフィス
内容: この勉強会は毎回OpenPNE3の各機能、仕様にフォーカスを当て、ベースフレームワークであるsymfonyを理解していく勉強会です。
参加者はみんなsymfonyに興味のあるプログラマです。Webエンジニアとのネットワークづくりにもお役立てください。
■Python4PHPer 第7回講習会
URL:
http://atnd.org/events/6344 日時: 2010/08/12 10:00 to 22:00
場所: 国立オリンピック記念青少年総合センター
内容: Python未経験者向けの、PythonとGoogle App Engine (GAE) の入門講座です。
■第11回 LOCAL PHP部勉強会
URL:
http://atnd.org/events/6443 日時: 2010/08/28 14:00 to 16:30
場所: 札幌市産業振興センター セミナールーム9
Yii 使ってる?
遊びで使ってるけどなかなか良い感じ でもまだ公開サイト用はcake使ってる もう少し日本人ユーザー増えればいいのに
Yii使い始めた。スレ立つと寂れるかな?
フォーラムもYiiDocもYiiJan(だっけ?)も活動してないっぽいしなー まぁここ半年くらい書き込みなくても早々落ちるような板じゃないし、スレはあってもいいと思うお
新規案件があったらYii使おうと狙ってるのだがなかなか良い感じのが無い 何かお題目無い?
>>460 ベニーオークション
情報共有したいなー
今んとこ躓くほど触ってないけど
やっぱそこかね 英語理解するのちょっと時間掛かるんだよなー
Yii は、フルスタックとかぬかして規模がでかいだけのフレームワークに比べてシンプルなのが良い。
開発者が増えてきたときに 設計の良し悪しが解る 今はまだ判断するときじゃない。
国内で商用で使ってみた人はまだいないだろうけど 個人的に公開されたサイトで利用してる人っているんだろうか
kohanaがいい Yiiは簡易過ぎる
簡易っていうと機能が足りないって意味か?
kohanaは知らんけど、yiiは使い勝手よさそう
yiiは海外だけあって活発でextensionが多い印象。 kohanaはユーザに日本人が多いのが良さそうだね。
多いか?情報少ないっしょ
本当に印象だけだなw kohanaはマイナー yiiはそれ以上にマイナー
海外だと単純に逆じゃね?
yiiなんて英語版Wikipediaの記事すら作られてないレベル Codeigniterの正規化のkohanaの方がまだメジャー
メジャーといっても両方ともサービス実績少ないのは同じことかと。 そして実際kohanaのextensionはyiiに比べて少ない。
extensionの数を競って何がうれしいんだ
選択の幅が広がるのは良いことでは? 質にもよるけど。 別にどちらかの肩を持つわけではないので 確かにCodeigniter派生のkohanaのほうが知名度が あるというのは納得。
extensionの数はそのまま、ユーザ層の厚さの違い。
えっ
このスレでどっちがマイナーかなんて競ったってしゃーないわw 自分はYiiしか知らんかったから、Yiiをさわってみてる Codeigniterあんま好きじゃないしw
>>478 車輪の再発明が好きな無計画なユーザが多いだけだろ
ちっちゃいなぁ
新しくものを覚えるのが難しい人たちが コミュニティの対立を煽る。 ほっとけ。
ようやく明日Yii本(俺はebookだけど)発売日だzeeeeeee。 つーか、ドキュメントを何回も読み返してソースも解読して、 だいぶ慣れてきたけどなー。 つーか、慣れたところで独法系のお試しプロジェクトとか、 ヴェンチャー系の新しいもん好きプロジェクトしか金に ならなさそうだけどなーーー。ま実装形態とかdbの思想が 違うだけで、やってることはCakeとあんま変わらんけどなーーーー。
>>484 あぁ英文のか。
yiiはconditionの書き方がcakeと結構違うので戸惑う
っていうかよくわからない。
俺はロシア語の資料だって挑戦するからな。 ただgoogle始め機械翻訳がバカ過ぎて、辞書引き引きになって 語学やってんのか、ドキュメント呼んでのか分からなくなるが。
英文はともかくロシアはすごいなあ。 ネットで見てもまず無視するわ。 yiiってscafolldingが綺麗だから そのままでも結構使えて便利。cakeはそのまま使う気にはなれない。
だれかkohana日本語で解説してよ
>>487 ハングルにしてもキリルにしても一週間でも集中して語学っぽくやれば
読めるようになるぜよ。さすがにアラビア文字はいまだに読めんし
ギリシャ文字は必要に迫られんから読もうとは思わんが。
韓国はネトゲエンジン、ロシア・ウクライナは洋ゲーで日本より前進
してる部分があるから、PHPのFWやる限りはあんま必要ないが、
開発ドキュメントは面白いのが埋もれてる。まぁgoogleで大体は
こと足りるけど、半分くらいは出鱈目な結果になって結局自力で
細かく翻訳する羽目になるんだよな。特にロシア語は内部で
変換してる露英辞書が貧弱すぎるきらいがある。スレチすまん。
Yii本発売日伸びたな。サイトは15日、尼は16日になってる。
>>488 べたーこーどいぐにったー
ぐたいてきには、PHP5おんりーなこーでぃんぐ
これで不足ならソース嫁
ようやくYii本DL始まったわぁ
英語の壁すら突破しきれてない俺に他の言語なんて… とかなんとか理由つけて逃げてるだけなんですがー
コードイグナイたんっていうキャラ作ったらかわいいんじゃね?
それなんてCIたん?
giiいいね yiicのころさわったきりだったけど、こりゃ楽だわw
>>496 giiはまだ公式で日本語訳(どころかフランス訳すらない)から
見過ごされてるな。yii本には載ってたが。
英語で公式読むか、ディレクトリ舐めるように見回すと気づくんだろうが。
確かに最初yiic覗いた時、「何このはりぼて?」と思った。プロジェクトスケルトン
吐くのに急いで公開したんだろうか。
リリース後のTOPで紹介されてるときに触ったからどういうのかは知ってたけれど 言われてみると確かにドキュメントがなくて気づかないかもしれないw Creating First Yii Applicationの日本語のほうは1.0のyiicでModelとか作る奴のままだしな
yiiってphpをcgiモードで動かさないとダメ? たまにsafeモードでファイル作れないよ!と怒られるんだけど回避できないかな
それモジュールだとsafeモードな設定のレン鯖とかでやってるだけじゃん フレームワークとは関係ない
yiiの本がアメリカ語だか嫌になる しかも本家も翻訳されてないとこ多くていやになる
せめて同じジャンルで比較しないと返し言葉にならないのでは…
てかよっぽどの新機能でもない限り、ちょっと仕込めば 量産はアクションとコンテンツブロックだけ書けばさくさく作れるし、 もう他はどうでもええわ。Yii本はまぁご祝儀買いってとこか。 ethnaはgreeった時点でさようならだからどうぞご自由に栄華を 極めてくださいって感じ。cakeは何か変わったことすっと落ちるからもう戻れん。 一人でやってると今や一番面倒なのはHTMLのコーディングになっちまった。
俺もEthna使ってたけど釣りゲーム訴えてから使うのやめた
Yiiをブログで扱う人がぼちぼち増えてきた感じがする
もう3年以上も経ってるからねぇ とはいえ、まだethnaよりも情報が無い状態 しかも未だ日本語の翻訳が未完全という・・・・・ Yiiの本が翻訳されれば爆発しそう何だが誰かとりかかってるのだろうか?
509 :
nobodyさん :2010/09/05(日) 01:18:31 ID:ruHJBgsy
匿名で書きたいからスレ立ててよ googleサービスとか捨てアド取るにも携帯認証必要だからやりたくない
まぁネラーとしてはここだよなw
スレ違いだったらすみません。 yiiを見ているのですが、下のソースはどういう意味でしょうか? Yii::createWebApplication($config)->run(); Hoge::foo($config)->huga(); この書き方はスマートでよさげなのですが、どういった構造になりますか? ↓ではないようなのでさっぱりです。 class Yii { function :createWebApplication($config) { ... } function run() { ... } }
static
>>513 レスありがとうございます。
staticでも試してみたのですがこの書き方だとFatal errorがでます。
Yii::createWebApplication($config)->run();
class Yii {
static function createWebApplication($config) {
...
}
function run() {
...
}
}
static function run(){}にしてもFatal errorでした
class in
516 :
514 :2010/09/06(月) 18:07:36 ID:???
すみません。あげます
createWebApplication($config) の戻り値は? そのrunメソッドを叩いてるだけだと思う。 Yii知らないけど。
>>514 エラー内容も書こぜ
おそらくこんな感じ
class Yii {
static function createWebApplication($config) {
return new Yii($config);
}
function run() {
...
}
}
yii.phpのソースはこんだけ require(dirname(__FILE__).'/YiiBase.php'); class Yii extends YiiBase { }
これからフレームワークを習得するならYiiがいいの?
>>521 趣味で遊ぶ程度ならyii
しっかりやるならcake、zend、symfony
yiiが今後どうなるかわからない。
様子見
ethna最強伝説
Rhacoこそ至高だし
>>521 >>522 >しっかりやるならcake、zend、symfony
Cakeとかもうないだろ。今安定したのがいいのなら、Symfonyじゃない?
YAML各野にうんざりで投げたけと。
これから伸びそうに見えるのが、KohanaとYii。
まだ本リリースされてもないのに注目されてるのがLithium。
本命はないから好きなの選べw
ZendとKohana以外使う気がしない
自分が使ってる物最強って言うだけなんだから 他人に意見なんざ聞くだけ無駄 理由に周りはとか採用実績とかつけてさ
後発なだけあって出来いいから、言語の壁が高くないならYiiはイイよ
つーか、そもそもどれを使うかの決定権が無ければ所詮遊びだろ
Yiiのblogデモのコメント検証のエラーメッセージってどこでカスタマイズするの? やりたい事はメッセージの日本語化 'language'=>'ja',としても英語のままでござる
yii本体の中にあるメッセージファイルを 各アプリのファイルに置き換えればok
最先端なフレームワークでもそんな風にしないと駄目なのね… がっくし…
お前が欲しいのはフレームワークなのかエスパーなのか
結局、yiiは駄目なのか
>>530 ブログデモをそのまま使うわけではないよな?
バリデーションに関しては、定型的なのは config/main.phpのlanguageをjaにすれば、日本語化される。変な日本語だけど。
独自のメッセージを出したいときはrules()の中で、messageを定義すればOK。
public function rules(){
return array()(
array( 'name', 'required', 'message' =>'名を名乗れボケ!' ),
array( 'mail_addr', 'email', 'message' =>'メアドが違うぞコラ!' ),
);
}
できるだけframeworkの中のファイルは修正しない方がいい。
やっちゃったことあるけど後々めんどい。
>>530 >'language'=>'ja',としても英語のままでござる
この時点でおまいの設定が間違ってる
yiiはデモが少ないのが玉に瑕 エクステンション別にデモ置いてくれたらいいのに 何が何だかわけわかめ!
yiiを始めました 初歩的な質問なのですが自分で作ったクラスはどのフォルダに置けばいいのでしょうか?
>>538 汎用的なクラスならcomponentsの直下に置くと、大抵はrequireとかしなくても使える。
モデルやコントローラなら、それぞれそこに。
フレームワーク始める前にPHP勉強しないかみんな
最初からフレームワークでも最初からWordPressでもいいと思うけど Ruby信者じゃあるまいし、必要なことだけ覚えればいい
>>541 必要なことすら覚えてないから恐ろしく基本的な質問が連発されている気がするが…
つーかむしろRubyの所もいきなりRoRやってバカみたいな質問出まくってるけどさ
バカな質問いいじゃない。答えたくなければ無視すりゃいいんだ MLじゃないんだからさ。Rubyのスレは別世界だし。
答えたくないなら無視すればいいとか言う話じゃなくて、 基本の勉強もしなさいよと言う助言だろ。
PHPを扱う職に就きましたが、前任者の書き方が独特なので後任者一同困っています。 今後そういうことを起こりにくくするために、フレームワークを導入しようと思っていますが、 結局どのフレームワークが最良なのでしょうか? Webコーダーの人たちにも理解しやすいものがいいのですが…。
Zend…かな
>>546 フレームワーク選定とコードの読みやすさは関係ない。
コードを誰でも読めるようにするためには、コーディング規約を決めて、全員で守る。これしかない。
最良のフレームワークっていうのも、人によって答えは違う。
バリバリMVCしていきたいのか、気軽な自由度がほしいのか、PHP4環境も考慮の必要があるのか?
目的がわからないと答えられないよ。
フレームワークを使ったら コーディング規約はもはや不要だよ。 フレームワークのやり方と命名方法に あわせろで十分
>>549 ZendかKohanaしか使ったこと無いのかな?
SymfonyやらCakeやら、PHP4時代を引きずってるフレームワークを使ってみれば、
命名規約とか却って本当にぶれぶれになるぞ。それこそ泣きそうなくらい。
ん? Symfonyは最初からPHP5専用なはずだが。 命名の基準がわかりにくい、というかカオスなのは同意だけど。
Symfonyはmojaviのフォークだから、 PHP4時代を引きずってると言える、のかもな。 PHP自体、命名規約がないに等しいカオスだし。
Cakeなんて逆に規約ガチガチ過ぎてぶれようがないだろ 完全オブジェクト指向じゃないってだけで
フレームワークの選定なんて、要件とメンバーのスキルや好みで決めれ 最良なんてのはない、どれが最適かは案件しだい あと新しく手をつけるのなら資料の多さもおおきいよ たとえばYiiは、出来はよさそうだけど、日本語ドキュメントが少なくてYiiとかいまいち下火だしな
むしろZendやKohanaの方が自由度が高くて規約で縛らないと偉いことになる気がするけど SymfonyやCakeは規約から外れると動かないから
>>555 それは仕組みの話であって、規約の話じゃない
こと命名に関しては、Zendは一貫してる
一方、
$this->User
なんてのを一貫した命名規則で扱うのはなかなか難しい、と個人的には思う
# これ、MS方式?
>>546 です。みなさんありがとうございます。
規約ガチガチのフレームワークというのは、扱いにくいものなのでしょうか。
扱いにくくないのであれば、その規約に従ってみんなが書くようにすればいいだけなので
僕の困っている点を解決するのにピッタリな気がします。
ただ、困っているのは命名規約よりもファイルの読み込み方や変数・配列の使い方です。
読み込んだファイルの中で別のファイルを読み込んで、そこからさらに別の…というふうになっていたり、
セッションや$GLOBALSでデータを回したりしているようです。
仕様書のようなものもありません。
こういうのはフレームワークではどうにもならないでしょうかねぇ…。
>>557 多少は癖が出るもんだし仕方ない
防ぎたければある程度のお手本となるマニュアルを作るべきでは?
>>558 そうですね。この機会にマニュアルを作るのがいいですね。
自分のやり方も癖があるかもしれないので、周りと相談してみます。
フレームワークもやっぱり気になるので、
>>2 にあるような有名なものを
ちょっと調べてみようと思います。
ありがとうございました。
>>557 それはフレームワークではどうにもならない。
$_SESSIONも$GLOBALSもスーパーグローバル変数で、
そもそもグローバル変数の利用からして制限できないから。
方針としては、バージョン管理を利用したコミットの受け入れチェックなど、
管理面での対応が多分あなたの要件に適したものだと思う。
ソースコードをgrepして、
→ global キーワードは無条件でアウト
→ (ライブラリ以外で)$GLOBALSが存在すれば無条件でアウト
→ (ライブラリ以外で)$_SESSIONの利用も無条件でアウト
→ フレームワークのセッションアクセスメソッド($this->getUser()->setAttribute() など)を
重点的に監視
などなど、「これはダメ」って言う基準作りが先。
フレームワークが有用とすれば、
>>558 の言うとおり「お手本」を定型で示すことができる、
って部分があるかもしれない。
>>560 なるほど。
自分でも何が良くて何が悪いのか頭の中ではっきりまとまってないので
まずは明確な基準作りですね。
バージョン管理も現在は特別なことをしてないので、これから勉強してみます。
とても参考になりました。
ありがとうございました。
それでもクラス変数という抜け道がげふんげふん
抜け道を心得てるような人はちゃんと実装できるでしょw
一番重要なのは規則を作ることじゃなくて、個々のスキルと意識の高さだけどなw どんだけちゃんとしたルール作っても、中華コーダーが混ざってるだけでダメになったりする あと、拘りがある人、というか堅物や変人とかがいると、 俺はこういう書き方をするんだ!って主張したがるから、そのあたりも非常にうざいことになるw
は?
>>564 個々のスキルと意識の高さが重要なのは同意だけど
コーディング規約を守らせられない現場はどうなってるんだ?
派遣の寄せ集め所帯なら仕方あるまい
ベンダコントロール能力ゼロの無能PLってことだろ
新選組みたいなもんだ 土方歳三レベルのPLでないと纏まらん
いや大多数のプロジェクトでは普通に規約守られてるだろw
派遣の寄せ集めでも規約は守らせるだろ 最初の1週間はしょうがないかもしれないけどさ。 ここはフレームワークスレなわけだけど フレームワーク使ってるならなおさら規約は守るものだと思うけどな
最初に規約の説明とフェーズごとにコードレビューやるかどうかだけであって 外国人がいようが慣れてない派遣がいようが関係ない話だろ 別に規約はそんな重視しないで自由でいいよって方針のプロジェクトも多いけど 守るのが前提ってプロジェクトで守れないのは単にリーダーがバカなだけ
でも実際そういう案件も腐るほどある現実 規約があってもコードレビューとかやる余裕のないとこだと、 結局形だけのルールになってたりするのも見るしな なんにせよ、フレームワークとはあんまり関係ないけれど ただ糞みたいなコード書いてるような案件は、俺俺フレームワークを作ってるか、 既製品つかってても、使う意味がないような使い方しかしてないことが多いわなw
規約守れないなら少なくともCakeは絶対無理だと思う
>>573 そんな低劣なとこと仕事してるのか。
お前みたいな底辺は大変だな
建築現場だとぶったたいて教育できるけど ITの現場はぶったたくと死んじゃうからなぁ PMおつかれさまです!
ITの現場ならコーディネータ呼んで あいつなんとかなんないならお宅の会社更新なしね で一発だけども
せちがらい
>>576 みて、ちょろっとDooPHPいじってみた。普段はYiiを使ってるんだけど、
・ブログデモの動作はほとんどノートラブルでできた。設定は簡単。
・アソシエーションを設定ファイルの配列で定義。
・モデルにrelationInsertとかそういうメソッドがある。ちゃんと動作するなら裏山
・insert/updateを分けて呼ばなくてはいけない? めんどいー
・独自テンプレート? ちょっと今更感がある
既存のフレームワーク以上にクセが強そうに見えるんだが。
間違いあったら誰か指摘してくれ。
>>580 cakeしか知らんのだが、relationInsertの使い道としては
使い捨てのリレーショナルが簡単に組めるってことなの?
>>576 これ、modelは自分でいちいち書かないと駄目なのか?
modelってのはたぶんテーブル定義のことなんだろうけど、 コードに定義が書いてあるのは結構好きだな。 コードだけ見ればデータベースの設計がわかるから。 RailsとかDjangoみたいにコマンド一発でデータベースに テーブルが追加されたりするのかな 公式ページ上部のメニューバーがFlashなのが微妙
>>583 どういう畑で作業してるのか知らんが、
ある程度の規模だと、構造設計・実装とDB設計は別になるだろ。
てか、DBの構造をコードから判断とか、バグ(仕様把握ミス)の
温床以外のなんでもないんだけど。
ドキュメントが整備されるならドキュメント。
整備されないなら、admin系ツールでちゃんと確認して組めよ。
ま、お遊びプロジェクトで遊ぶんならいいんじゃね?てとこ。
何を言ってるんだお前は
>>584 それは言い過ぎ。
モデルをきれいに書けば、誤解しようのないコーディングが出来る。
ドキュメントもきちんと書かなければ、バグの温床になるだろう。
きっちり書かれてない紙切れはドキュメントとは言わないだべ エクセルだろうけど
Excelで書いたから駄目という理由が分からんけども。
Excel仕様書でまともにドキュメントを管理できてる案件にまだであったことがない かといってWordだと馬鹿連中が書きながらどんどんぶっこわしていって、手のつけられないような酷いことになる方が多い どちらがいいとはいいきれない。一長一短
スレチうぜー。アッチデヤレー
>>589 お前が配属されるプロジェクトがことごとくレベル低すぎなのは解ったから
自分の能力の低さを自慢しないでくれ
フレームワークを学んだ得たこと CakePHP,Zend 1.売れるシステムにフレームワークは関係ない 2小規模なシステムは一人で構築した方が早い。フレームワークでチームでやるメリットがない 3.毎度毎度、違うシステムを作るわけではない。なんでも作ります屋さんは案件とれない 4.フレームワークを習得するのに時間がかかる。その間に売れ筋のシステムを構築できた。機会損失もあわせて、でかい 結果、1〜2人で制作する分にはフレームワークはいらないし フレームワークのおかけでもう儲かった利益はなく、習得してから2年経過するけどマイナスでしかなかった フレームワーク = 重いというイメージさえついてるから売りづらい
>>592 そんな化石世代のフレームワーク持ち出されてもなぁ。
OpenPNEなんてSymfony採用してからプログラマの参入障壁が高くなって プロジェクトの進行やアイディア不足に衰えを感じる。 しっかりとした枠組みが必ずしも流行するわけではない。 phpがWEB言語として活躍できてるのは、とっつきやすさにあると思う それをあえてフレームワークで難しくするのはPHPのメリットを殺してると思う プロジェクトに参加できる全ての人が天才ではない 集団の英知を実現させるのなら、規律が最小限のフレームワークである
フレームワークでどれだけの利益が出たか? 俺はほとんど利益に貢献できてないと思う。 新しいフレームワークが出れば、それを覚えるのに時間がかかる これを繰り返すくらいなら、フレームワークなしで売れ筋のシステムをたんたんと作ってた方がよい
新しいフレームワークが出れば、今までの蓄積リソースは無駄になる これって毎度毎度、無駄にしていかないといけない これでは利益率は上がらない
保守性低い
新しいフレームワークを使わなきゃいいだろうが
フレームワークを使うなら新しいのじゃないとメリットがない 改善されて使いやすくなってるから
結局フレームワークに躍らされる時間が無駄ということ フレームワークと騒いでるやつほど、利益貢献してないと思う システムは売ってなんぼ
古いフレームワークは複雑で難しいよね。設計が練れてないから。
CakePHPを習得して構築してるときが一番儲からなかった。 フレームワークにして儲かったてやついるの?
フレームワークを使う使わないの判断が適切に出来ないやつが 儲かるわけないだろ!
フレームワークの適切な判断を誤ったから 確かに儲からなかった。 フレームワークと騒がれて、すぐに飛びついたのがよくなかったかも。。。
フレームワークは道具にすぎないのに 儲かる儲からないは別の次元では?
フレームワークを使うのはリスクはあるよ ハイリスクノーリターンになっちまったけど 使わなければノーリスクでノーリターンで普通に儲かってた
仕事だと思って話してるから、行き着く先は儲かる儲からない ボランティアや自己満足でやってるなら次元は違う
それもどうかと
儲かる儲からないを意識してフレームワークについて 話するのも良いと思うし そんな次元の遠い話でもない
>608 ノーリターンの意味が・・・w フレームワークって言葉に踊らされすぎな気がする。 どの言語なら論議に似た、レイヤのズレを感じるぜ。 ところで、ここでいう売りって何だ? システムそのものを売るの?サービスを展開するの?
馬鹿と鋏は使いよう 鋏が使えなくても紙を切れないわけではないし 馬鹿だって倒れたペットボトルを立て直すための機械を導入するよりは低コストに導入できる 儲けるためにどうするかなんていいつつ、道具を使うことそれ自体を目的として考えてる時点でお門違いもいいとこ(笑) そんなんだから、その程度の仕事にしか縁がないんだろうな、って話になっちまう だいたい、使うか使わないかを検討する以前に、使えないから使わない方が効率いいんじゃねw
613もっとわかりやすく書いてくれ。 可読性の悪いコード書きそうだな。 いっしょに作業したくないってよく言われるだろ
>>612 どの言語なら論議に似た、レイヤのズレを感じるぜ
どういう意味?かっこつけなくていいから
普通に書いてくれ
別にフレームワークに対して疑問もっていいじゃん。 疑問を持たずに、言われるままに使っているほうが、頭どうなのと思う。 フレームワーク自体は必要だと思うけど、その学習コストはもっと問題にされていい。 Smartyのような大規模なフレームワークはもう廃れていいよ。 今までのフレームワークをLispにたとえると、これからは機能を厳選した、 Schemeのようなフレームワークが流行ってほしい。
フレームワーク誕生のおかげで覚えることが増えただけで これといった見返りがない。そういう人は他にもいると思う OpenPNEだって、フレームワーク選択の失敗例だと思ってる。 乱立してるのが一番よくないと思う 早く天下統一してくれ
phpだけじゃん乱立してるの まあ、それほど人気のある言語だから 仕方ないか。 フレームワークてどんどん進化していくから 作業効率を求めれば、おれおれフレームワークになってしまう 進化や乱立についていってたら、えらいコストかかる
どーでもいーけど、マ板ム板に近いこの板で、 >>とか全角数字とか使ってる奴見ると、なんか気持ち悪くてしょうがない。 しかしこのスレ、相変わらずフレームワークとはあんまり関係のない話題でしか進まねーなw
自分が例えばSymphonyを使いたいとしても 同僚はCakePHPしか使えないかもしれないですよね。 皆さんはそういう状況はないですか? どうやって対処するんでしょう・・・。
>>620 よくあるケースだけに、対処も何も。
どっちかがどっちかを覚えるしかないだろうが。
おまいも同僚も、死ぬまで一つしか使えないの?
例えばMySQLしか知らなくてPostgreSQL無理、とか言っちゃう人?
>>616 smartyってフレームワークか?テンプレートだろ
2人って時点できちっとMVCしてなくても
おれおれフレームワークもどきは使ってたりしないか?
>>618 いやperlもカオスだよ
>>620 CakePHPしか使った事なくても、CakePHPの経験があれば
他のフレームワークも容易に覚えられる
社内でみながバラバラにやってたらカオスになるだけ
というかコーディング規約無いの?
>615 Javaなら、C#なら、PHPなら、Perlならみたいな話は大抵のスレで出てくるけど それってビジネスとは違う話だよね、みたいな。
PerlのWAFは今だとCatalystがほとんど。たまにCGI::Application、最近Mojoliciousがあるかなってぐらい。 それにPerlの場合、WAFを構成するコンポーネントはCPANのモジュールを流用する。 ORマッパーはDBIx::Classで、ORマッパーなしのDBレイヤーだとDBIで、まれにマイナーなORマッパーもあるけど。 テンプレートはたいていTemplate Toolkitで、たまにHTML::Templateがあるかなってくらい。 各WAFはこれらのORマッパーやテンプレートを取り替えて使えるようになってて、ロジックだったりビューだったりはWAFから独立してるとも言える。
PHPの場合、PEARの存在感が薄いという事と、なまじ組込みでテンプレートだとかセッションだとかが備わってるから、WAFの乱立を生むんだろうね。自分で簡単にWAFを作れるから。
>>596 例えば、ページキャッシュとか、便利で利用価値があるけど、独自で実装するのは結構大変だよね?
だけど、大抵のフレームワークなら、ちょっと記述するだけで簡単に実現できたりする。
scaffold何かの機能も開発していく上でかなり有用だし。
他にも利点を挙げればきりがないくらいあるよ。
デメリットは学習コストくらいでしょ?
全部のフレームワークを熟知するのは大変かもしれないけど、一個に絞ればそんなに難しいことじゃない。
>>2 で上がってるような有名どころから一個選んで、習得すればいいだけ。
俺は一通り触ったけど、どれも一長一短だからどれでも問題無いと思うよ。
こんなレベルの議論してるのもPHPスレのやつらだけだよな
>>628 >例えば、ページキャッシュとか、便利で利用価値があるけど、独自で実装するのは結構大変だよね?
えええ?実装、難しいか?
キャッシュこそ、expireするタイミングとかキャッシュデータの保存先とか
プロジェクトによっていろいろ変更したいから、フレームワークが
そのまま使えなくて手を入れる必要がある機能の典型例じゃないかな。
>デメリットは学習コストくらいでしょ?
そのコストが高すぎるんだよ。チュートリアル読んでできることなんて
限られてるよね。どのフレームワークでも結局ソース追っかけていかないと
いけなくて、それも学習コストに含まれるんだよ。自前で書けばすぐ済むのに
フレームワークの妙な制限のせいで問題解決が遅れ、ソースコードをたどって
改修することが何度あったことか。
学習コストを問題にしてないのは、フレームワークを表面的にしか使って
ないからじゃね?ディープに使いだすと、大規模フレームワークほど
むちゃくちゃ学習コストが跳ね上がる。
なんか使い方がズレてる気がする
俺も学習コストが高いと思う口なんだが テンプレートやらをつかったMVC的な物は使いたいのよね こういうのを自前でやる知識みたいなのは何の本を読めばいいんだ? 今はajaxやらwebsocketやらを強引にガリガリかくか、フレームワークを使ってやってる 各フレームワークのソース読めとかそう言うの無しで教えてくれよ
フレームワーク使うと具ぐる手間が、2倍以上かかる 天才でなければ、最初の1年は棒に振ったと思って取り組んだ方がいい
1年後には、また新しいフレームワークが出て 乗り換えたくなってもガマン 凡人にしてみれば、似たようなものと簡単に乗りかえれない
>>631 逆じゃね?
プロトタイプ的なものはFW使ってちゃちゃっと作っちゃって、
特殊なところ、凝ったことしたいところは後から自前で作りこんでく
のじゃダメなの?
小規模なプロジェクトじゃ手に余るしねえ・・・
まともな仕様書が無い案件ほど FWを使うと後々メンテが楽になるのでは? オレオレで組まれると何がどこにあるかが わからず時間が掛かる。
ころころ道具を変える人間と一緒に仕事したくはねえなw zfかsyかcpのどれか使えればそれでいい
お試しはするけどころころ道具変えられるようなプロジェクトなんてあんの?w
てかころころ変えたらフレームワークの価値半減w
zfとかcpっていう略し方は一般的なのか 細かくてすまん
ZFなら何回か見かけたことあるけど、cpとかsyは見たことない
ciはあるな
.^←これは海外のチャットでよくみる
それはフレームワークなのか
>>631 ページキャッシュの例えが悪かったのかもしれないけど、
expire/保存先その他諸々、普通のFWならそれなりに設定できる。
逆にこれらの機能を踏まえて実装が難しくないと言える程、webアプリケーションの開発知識があるのに、
学習コストを気にしてるのが信じられないんだが。
穴だらけのシステムしか作れないようなレベルだから、FWは難しくて使えないってことだろ 言わせんなよはずかしい…///
>>649 代弁してくれてありがとう。
俺の意見でもあり、真実でもある事をまとめると、
FWの学習コストを問題視している人は、プログラムに関する知識・経験・技術などが不足している人。
そんな厨が作るアプリケーションは、レベルに相応の底が知れてるもの。
ACLや多言語対応なんか縁もないPHP入門書なんかに載ってるサンプルレベルの開発をしているので、
FWのメリットが理解できない。
確かにhello worldやるだけなら、FWなんか使わない方が100倍は速いからね。
>>631 は頑張ってfopen()使ってhello worldをページキャッシュして下さい。
どちらかというと技術よりFWのルールを理解するのがアレなのよね
本当に大規模で今後長期的に運営するサービスとかなら、
独自FW開発するコストも相対的に下がるし、
外部プロダクトに依存するリスクも減らせるから
オープンソースFW採用しないのも理解できるけど
>>631 みたいな理由はよくわからない。
ただ「学習コスト」に対する心理的な部分では、 PHPそのものの言語仕様に対する「学習コスト」に比べて、 他人が作った枠組み・制約に合わせることを「学習」することに なんで俺様が時間を割かないといけないんだよ? みたいな壁があるのは否定しない。
著名人が作ったFWには説得力はあるよね FWを利用すれば、最先端のプログラム作法が、 苦労せず身につく 高度なプログラミングの方法論を大学へ行って 学ばなくてもみんなが共有できる
著名人が作ったFWっどれ?
greeの社長
使いたければ使えばいい、そんなもんでしょ アンチしたけりゃ専用スレ立ててやってほしいわほんと
CodeIgniterというのが良さそうですが、 日本語の資料が少ないこと以外に 何か欠点はありますか? 日本で普及する可能性は低いでしょうか。
普及してるかと。 というか、どんなものを作るのか明示しないと 誰もそのツールが的確か判断できないよ。
>>659 もう普及してるんですか。
得意不得意があるとは思わなかったので、
作るものを書きませんでした。すみません。
ECサイト、CMSや、小さいものだと
ちょっとしたツール(社内で使うようなもの)です。
復旧の度合いにもよるけど、FWの中では知名度はあると思う。 ダウンロード数で比べてみるとかどうかな。 CIはCMSには向いてるけど、ECサイトならもっと別の 専用のがあるのじゃないかな。 まぁ少しは調べてここに書いてみてよ。俺はCIあまり知らないしw
>>661 どんな用途でも一つのフレームワークで済ませたいと思ってしまったんですが、
やっぱりいろんなフレームワークを使えるようにしないといけないでしょうか。
調べてみると、CodeIgniterは比較的取っ付きやすいようなので
とりあえずやってみます。
ありがとうございました。
PHP4対応のフレームワークを今から使うのは個人的には敬遠したい 慣れの問題かも知れないけど
PHP5非対応なわけじゃないから、別にいいんじゃない? それともPHP5で使うと何か問題ある?
ソースを読むときにげんなりする privateならprivateって書いてある方が幸せ
もうrailsでいいんじゃないかな
>>658 CIは俺も好きだが今からやるもんじゃない
668 :
nobodyさん :2010/09/26(日) 11:08:20 ID:kWdN3TKg
PHP5.3のメリットをしっかり生かしてるFWがあったら5.3での開発手法の参考にしたいんだけど オススメは?
Synfony2
>>668 しっかり生かしているかとなると疑問だけど、Zendがいいかも。
ただ、どのFWも『PHP』のメリットを生かせてはいない感じだよね。
PHPなら$_GET/$_POST/$_SESSIONを使えるのがメリットだと思うし。
まあ、デメリットでもあるのかもしれないけど。
yiiはどうだろう
672 :
658 :2010/09/26(日) 16:53:52 ID:???
CodeIgniterについて引き続き調べたら、 セッションデータが丸ごとクッキーに保存されるとかなんとかで あまり良くないとわかりました…。 代わりに、CodeIgniterをベースにして改良されたKohanaというのが良さそうです。
日本語で解説してるのほとんどないぜ
674 :
nobodyさん :2010/09/27(月) 06:05:17 ID:KSEP+D6L
>>668 > PHPなら$_GET/$_POST/$_SESSIONを使えるのがメリットだと思うし。
意外かもしれないが、Yiiはこういうところを自由にできる
>>672 >CodeIgniterについて引き続き調べたら、
>セッションデータが丸ごとクッキーに保存されるとかなんとかで
>あまり良くないとわかりました…。
え、クッキーセッションがなんでだめなの?
>>676 POST/GETと違いデータがクライアント側に渡らないのがセッションの利点の一つなのに
セッションIDだけでなくデータもクッキーに入るのが嫌って意味でしょ
RoRではデフォルト。
yiiでmodel共通の処理ってどこに書いてますか? cakeだとオリジナルのmodel.php等をmodelディレクトリに配置すれば、 置き換えられたのですがyiiだとわかりません。
>>678 ModelというのはActiveRecordだと考えていい?
とすると、俺の場合はmodelsの下にCommonModel.phpとかを作って、
各々のモデルクラスではCommonModelを継承させてる。
他のアプリケーションにも使いまわせそうな処理なら
CActiveRecordBehaviorを使ってみることを検討するとよりいいかも。
>>679 なるほど、標準では共通的なメソッド等を書くファイルというのは
決められていないようですね。
正攻法っぽいbehaviorを検討してみます。
ありがとう。
こんにちは。Rasmus Lerdorfです。 名スレの予感
>>682 Rasmusです。Matzさん、ご無沙汰しております。
その後ご機嫌いかがですか。
>>677 >POST/GETと違いデータがクライアント側に渡らないのがセッションの利点の一つなのに
えと、なぜそれが利点なんでしょうか。渡ると何か不都合がありますか。
改竄
盗聴
>>685 クッキーセッションでは、SHA1などをつかったハッシュ値と、サイトごとの
秘密キーを使って、改ざんを検出している。
だからそれをクッキーセッションの欠点とするのはおかしい。
>>686 それを心配するなら、クッキーセッションじゃなくてもセッションIDが
盗聴されることになるので、やはりクッキーセッションの欠点ではない。
$_SESSION['pass']='hoge'; と setcookie("pass", "hoge"); の差は明らかだと思うぞ ところで$_COOKIE['pass']='hoge';って書き方できるの?
>>688 前段の意味はよくわからない
> ところで$_COOKIE['pass']='hoge';って書き方できるの?
代入は可能だろうけど、setcookieはされないだろうね
最近のPHP(特に5.3〜6)はよく知らないんだけど
PHPは組込みでセッション機能持ってるんだから、それをそのまま使った方が良いと思う。 オブジェクトにする必要性もあまり感じない。 ファイルハンドルを透過的に保存復元したいとかかな。 確実に処理が遅くなるってデメリットに対して、大きなメリットを感じない。
>>690 >ファイルハンドルを透過的に保存復元
これの意味がわかんないけど、
俺は複数台サーバ構成の時とか、セッションのDB対応とかの時にメリットがあると考えてる。
>>691 > 複数台サーバ構成の時とか、セッションのDB対応とか
これって頭の中では同じ事想定してないか?
セッションのDB対応も、結局はPHPの関数インターフェイスを利用するわけで、
はてはレプリケーション対応のため強制的にマスターDBをアクセス対象にする
設定とかもその中で可能なわけで…
それを「クラス」でやるか、なんかしらん「インクルードファイル」でやっちゃうか、の
違いでしかないと言われればそこまでだよなあ、と思わんでもない
どっちかっていうと、PHPが準備していない、「セッション名前空間」的な、
仮想的な上乗せ機能の方にメリットを感じるなj
共有ディレクトリを使うか、session_set_save_handler()で入出力処理を書けば良いだけ。 ファイルハンドラは普通にやってもシリアライズ出来ないから、ユーザがアップロードしたファイルを画面遷移しつつ引き回そうとすると、単に$_SESSIONに値を入れるじゃ済まない。 しかし、ほとんどのフレームワークって$_SESSIONをラップしてるだけだろう?
>>693 アンカつけような。
おまいが言ってることの大半は
>>691 向けか?
>>692 ですでに半分くらい言われてるぞ
大体、ファイルハンドラのシリアライズ・引き回しって何だよ。
やるとして、受け付けたファイルの「中身」をDBなりなんなりで
持ち回すしかないんじゃね?ハンドラ?
PHPの場合、セッションが標準インストールで組み込まれている。 ウェブサーバ分散とか、ローカルファイル以外への永続化とか、十分な機能を持ってる。 だから、自前でセッション機能を実装する必要性はほとんどない。 また、セッション変数はスーパーグローバルになってて、その実態は単なるハッシュだが、それで困ることもほとんどない。 ただ、ファイルハンドルみたいなリアライズできないデータは、単なるハッシュへの代入では済まされない。 シリアライザの問題であるけど、データ型に関わらず透過的に保存できるならその方がいいし、そうするとセッション変数をオブジェクトにしてその処理を隠蔽する必要が出てくる。 とはいえ、そんなケースは滅多にないかな。
ここで最大の問題は、
>>691 がPHPの標準セッション機能では「複数台サーバ構成の時とか、セッションのDB対応とか」出来ないと思ってる事にある。
697 :
nobodyさん :2010/10/04(月) 18:15:08 ID:knLsFBRF
世界最軽量mvcフレームワークありましたらどなたかおしえてください
ひさしぶりだなちぃたん。元気してた?
気軽で軽量なPHP5FWないかねえ cakeやzendなんて余分すぎる
CakePHPどう?
cakeイラネ
ちぃたん… 名前だけでアウトだわ
704 :
691 :2010/10/04(月) 23:17:02 ID:???
>>696 別にFW使わないと「複数台サーバ構成の時とか、セッションのDB対応とか」
が出来ないとは思ってないんだが…
session_set_save_handlerでごにょごにょするより、
FWの設定でやった方が、実装コスト・保守コストとか含めてメリットがある
と言ったつもりだったんだけど。
軽量って言ったらCIかKohanaじゃない。 Kohanaは使ったことないけど。CakePHPは軽量じゃないよね。
rhaco2もphp5だよ
rhacoはないわ
PHPフレームワークにテンプレートエンジンていらなくね?
いらないと思う。むしろピュアPHPのviewのほうが楽。 SmartyやPHPTALに慣れたデザイナーがいるとか、状況にもよるだろうけど。
こはな?どれだけ使ってる人いるの
>>709 そういえば、PHPのView利用では一般的に
<?php foreach ($array as $value) { ?>
<p><?php echo $value; ?></p>
<?php }; ?>
じゃなくて
<?php foreach ($array as $value) : ?>
<p><?php echo $value; ?></p>
<?php endforeach; ?>
みたいにend***使った書き方が推奨されるのはなんでだぜ?
{ }のほうが、IDEとか(Eclipse以外は知らないけど)で
ブロック閉じの対応が見れるし、そもそもなんのデメリットがあるのかよくわからない。
さらに言えば、PHPのショートタグは有効でもいいと思う。
不都合なのはXML宣言のときくらいだよね?
<? foreach ($array as $value) { ?>
<p><?= $value ?></p>
<? } ?>
これが一番書きやすいし読みやすいと思うんだ。。
オライリーの本読め
714 :
711 :2010/10/05(火) 19:48:19 ID:???
とりあえずZFではPHP Viewはend***の記述法が推奨されてるけど、
>>711 に書いたようにメリットがよくわからないので守ってない。
あとはインデントの4文字スペース、最初は守ってたけど
効率悪いから途中でタブ使うようにしてしまった。
これもIDE使う前提ならタブのほうが良いよね?
ちいたんでHello worldを表示するサンプルおしえて
フレームワークと関係ないし好きにしろよ
>>716 フレームワークのコード規約守ってないの?
>>711 ショートタグは環境依存するから非推奨。
タブインデントはエディタ環境に依存してしまうので非推奨。
end***の記述方法は、入れ子になった時の視認性。
という感じかと・・・
律儀に守る必要は無いけど、
「推奨されたコード規約に準拠している」事自体がメリットになる場合もある。
>>718 まあFWの性質上、環境依存になる要素を
極力減らす方向の規約はわかるんだけどね。
でもショートタグはZendServerでもデフォルトでONだし、
いまどきのエディタ・IDEでタブインデントが
問題になるようなことはほとんどないかと…
それなりのFWの規約なら、逆に開発環境のほうを要求して最適化させる
方向性でも良いような気がするんだけどねえ。
ただend***の記述方法は「入れ子になった時の視認性」のメリットもよくわからない。。
ifとかforeachの閉じ種別が判別できるだけで、入れ子の対応は関係ないよね?
もしかしてそっち使ったほうが書きやすいIDEがあるのかな?
>>719 >まあFWの性質上、環境依存になる要素を
>極力減らす方向の規約はわかるんだけどね。
これにつきるよね。
>それなりのFWの規約なら、逆に開発環境のほうを要求して最適化させる
>方向性でも良いような気がするんだけどねえ。
個人的にもIDEは必須だと思っているけど、
FWとIDEをセットで学ばせるとなると学習コスト含めて導入の敷居は跳ね上がるからなぁ
FWではなく開発側で定めてしまえばいいかと。
>ifとかforeachの閉じ種別が判別できるだけで、入れ子の対応は関係ないよね?
>もしかしてそっち使ったほうが書きやすいIDEがあるのかな?
テキストエディタで検索しやすいとかかな?
タブorスペースインデントの話題とかはもうおなかいっぱいだわw んなもん規約にあわせてコミット前に置換なりかませりゃいいだけの話 つか最近のIDEつかってれば勝手にやってくれるから意識する必要すらないんじゃね checkstyle入れてても、警告バリバリの俺が書きやすいと信じるコードを書きまくる奴も、世の中には腐るほどいるし んなどうでもいい拘りを主張するやつが後を絶たないのも頷けはするけれど…
インデントはどこまでもついて回る話。PHPに限らず、ウェブアプリに限らず。
生phpのviewはescape忘れるアホがいるからなあ
素は普通にめんどくせえなw
725 :
691 :2010/10/06(水) 02:30:00 ID:???
>>723 それって例えばSmarty使えばescape忘れるやついないって思ってるの?
生phpのviewだとしても、変数をなんらかの仕組みでassignするような事してればいいんじゃないの?
>>725 ふつうは auto-escape する仕組みがあるから明示的な escape なんて要らないんだよ
smarty なら $default_modifiers でも使っとけ
>>725 その、何らかの仕組みでassignするようなライブラリがSmartyなんじゃないか?w
Smarty3からは生PHPでの記述に対応するし・・・
>>711 こんなところに俺がいた
まずは、ショートタグの復権が欲しいな
生PHPが読みやすいって、View側に関しては何の冗談だよと思ってる
>>721 拘りっていうかフレームワーク規約の話じゃないの?
フレームワークとテンプレートの違いが良く分かりません どちらもデータは別ファイルに分けられますよね?
申し訳ないのですがPHPでのテンプレートとフレームワークの話です ドヤ顔でgoogleさん張られても^^;
↑
触んじゃね 前にも似たような馬鹿沸いてて何人か釣られてたけど、 相手するような価値があるようなこと聞いてるか考えてからレスしとけw
>>729 FW使いたくない、テンプレート使いたくない(または使うほどでもない)って時のために
俺々ラッパー、俺々関数群を揃えたいとちょいちょい思ってるんだけど、
いろいろ考えてるとあれもこれもってなって、すぐピザになってしまう俺にはなかなか実行できないw
PHPのテンプレートは/プレゼンテーションフレームワークと言われるからな 意味の分からない人が釣られても仕方がないかな
だがPHP自体テンプレート言語
PHPはテンプレートとしても使えるってだけで、テンプレート言語では無い。
まあ、JSPみたいなもんだな。サーブレット使わずに、JSPだけで作られるサイトもあるし。
Etnaってどの程度使われてるの? 日本で作ってるっぽいから、どうかな、と思って。
使ってるのGREEくらいじゃね?w 一年以上更新無いし、汎用FWというよりはGREE用に開発してる感じがする。
>>738 少なくともクラス定義できるようになってからは違うでしょ
呆れた 真面目に使ってた時もあったから余計にね
呆れるという感覚が理解できない
えすにゃん・・・公式なんだぜ・・・? 1年以上更新放置してPHPカンファレンスで「今年はえすにゃんの一年でしたw」と発表してたぜ。 いくら国産でGREEでの採用実績があっても、これじゃなぁ・・・
OSSのプロジェクトに何を求めてるんだ?
えすにゃん以外
doophpのスレが撃ち落された
誰かdoophpでhello worldを表示するところまでをお願いします ブログとかに記事張っていただけたらアフィリエイトから5000円分まで購入させていただきます 広告張る場合、食料品の広告を是非お願いします
なんかすごく半端じゃない
yiiのscafolldingで作成したadminで、上部に検索boxがあると思います。 そこでリレーションしたテーブルを検索させたいのですが、 zii.widgets.grid.CGridViewに設定するcolumnに、 例えば"item.user"としても、user用の検索フォームが表示されません。 表示されるデータ自体はリレーションしたuserデータが表示されています。 これはどのような手を加えれば可能なのでしょうか? yii1.4です。
yiiのドキュメント見てる最中に公式がリニューアルされてデザインとレイアウト変わった Class Reference に Source Code も付くようになって参考になる
すっごい見づらくなったな… 得にエクステンション 最悪だ…
yiiでcssやjsファイルを結合してくれるエクステンションってなかったっけ? 知ってる人いたら教えてくださいまし…
森ウゼー
またyiiのサイト落ちてるよ…
所詮wiiのパクリ。
ヒーハー
$c=new CDbCriteria; $c->select=new CDbExpression('*,SUM(count) as summ'); こんな条件でfindAllしたときにsummの値がデータに入ってこないのはなんで? modelとかいじる必要ある?
わーい
いい
最近のPHPフレームワーク(+付随情報)を纏めないか? 他使ったことある人いたら、IDEとの親和性や生産性(ウリ)を埋めてほしく・・・ ●フレームワーク ・ZendFramework1.10.x IDE(PDT)親和性 [★★★★★] 動作速度 [★★★☆☆] 生産性 [★★★☆☆] コード規約がしっかりしているだけありIDE開発には最適。 動作速度に関しては、色々と便利なクラスが増えているが、コードが肥大化しているのが気になる。 使いやすい部分だけ使う、自作アプリケーション層のフレームワークを被せられれば生産性は跳ね上がる。 総評:そのまま使うのは厳しいが、基底ライブラリ/フレームワークとして使うと柔軟性が高い。一部のコンポーネントは重い。 ・ZendFramework2a (>= PHP5.3.x) 現状では1.10xとほぼ同じ・・・namapspace化された。 ・Symfony2 (>= PHP5.3.2) Lazyloadを多用した軽量高速になるはず? ・Yii 軽くて早いらしい。中身見てない。 ・rihaco Objectのアノテーション等が特殊、慣れれば面白そうだかがIDE相性悪そうなイメージ。 ●テンプレート系 ・Smarty3 ・・・ 正当進化、期待ほど伸びなそう。地味に便利になる。 ・Twig ・・・ Symfony勢の新テンプレートエンジン、Smartyに勝る多機能さ。 ・Dwoo ・・・ ポストSmartyかと思えたが、最近は更新も停滞気味。
Symfonyが普通にテンプレートエンジンを使えて、普通にパフォーマンスが出るなら もうそれでいい気がしてきてる。 Zendもいいと思うんだけど結局うわものの設計が必要で、Symfonyはそこまで作ってくれてる。 Cakeはもう覚えるのも人のコード読むのも気力が出ない。 てかCakePHPって(慣れれば)書きやすい(だろう)だけで絶対に読みやすくないと思う。
Cakeは今更感が
>>766 Template engineに、PHPTALないのが悲しい
>>769 ごめん、まともに触った事無いのは外してた。
足りない部分あったらガンガン書いてー
まとめてくから
>>766 Twigって知らなかったけどテンプレート継承できるのか。
便利そう使ってみよう。
りちうむってどうなったん
オレの感想。
使ってみたいなぁと思わせるのはSymfony2。
正式版でどの程度高速安定動作するのかが気になる。
・ZendFramework (
http://framework.zend.com/ )
PHPのZendEngine開発元であるZend社主体となったFWプロジェクト。
各コンポーネントが疎結合されており、フレームワークを作る為のライブラリ集に近い
PEARっぽいコーディング規約を採用しており、馴染みやすいかもしれない。
ZendFramework2からはPHP5.3対応となる。
・Symfony2 (
http://symfony-reloaded.org/ )
重いと評されたSymfonyとは全て刷新軽量。
ZendFWやDoctorine等、積極的にvendorライブラリを活用している。
・Smarty 3 RC4 (
http://www.smarty.net/ )
Smarty 2をPHP5ベースで完全書き直し、
継承しゃ代入、演算等の構文が追加されつつも、基本的な上位互換が保たれている。
最も盛んに更新が行われているが、1年以上かけても正式版は登場していない。
・TWIG (
http://www.twig-project.org/ )
継承や、柔軟な拡張機能がウリ。
中間コンパイルされるコードがPHPクラスで一時話題になった。
・CakePHP (
http://cakephp.jp/ )
Railsを意識したフレームワーク
フルスタックなので他のライブラリを使用ないで開発ができる。
ActiveRecordパターンのO/Rマッパー標準搭載。
PHP4対応でPHP4でもPHP5互換の関数使えるようにしているため
共通のソースコードでPHP4とPHP5の両方に対応できる。
互換性に強く古いシステムの移行に最適。
Cakeはもういいから^^;
>>774 > PHP4対応でPHP4でもPHP5互換の関数使えるようにしているため
> 共通のソースコードでPHP4とPHP5の両方に対応できる。
> 互換性に強く古いシステムの移行に最適。
ダウト
三行目の結論が論理的に導けない
上の二行で言っているのは、PHP4のサーバで動いていた「CakePHPの」コードが
そのままPHP5サーバに移行できる(可能性が高い)よ、ってこと、もしくは、
PHP4のサーバそのままで、Cakeで作った新システムに移行できますよ、ってことだけ
なので三行目は書きすぎ、というか根拠のない宣伝文句
せっかく紹介するのなら、嘘を書くなよ
で、それ以前にPHP4対応はさすがにニッチすぎる特色。
仮にも商売でやってるなら、PHP4対応とかもう勧めないでくれ。
もうちょいやんわり書けよ… 使ってる奴の評価なんて偏って当然なんだからさ…
>>776 何でそんなに必死なんだ?
ちなみにCakePHPはPHP6にも対応する予定で
PHPのバージョンの違いをかなり吸収してくれる。
幅広い環境に同時に対応させるのに最適。
主流のフレームワークでPHP6に対応しない予定のものなんてあるの?
PHP4に対応するが故に犠牲になっている部分が多すぎる>cake >ちなみにCakePHPはPHP6にも対応する予定で >PHPのバージョンの違いをかなり吸収してくれる。 吸収じゃなくて最大公約数的な機能しか使って無いだけだろ・・・ それともnamespaceとか無名関数とかSPLとかもcakeが吸収してくれるの? 嘘じゃないならバージョン差の吸収ってやつを具体的に教えてくれ。
いやPHP6自体が(ry
PHP4で動く事をメリットだと思う人は、プログラマとしてのリテラシーは最底辺だわな・・・ 「古いシステムがPHP4で作られてて・・・」って言い訳する人がいるけど、 実行環境がPHP5に移行してるなら、追加・修正する部分からでもPHP5に移行出来るのでPHP4で書くメリットは無い。 実行環境がPHP5に移行していないのなら、その時点で終ってる。 PHP5リリース&PHP4サポート終了まで移行期間が4年もあったのにね。
プログラマが最底辺なのに何言ってんの?
弱い企業とかなんじゃないの 金はかけたくないけど改修しろみたいな客からハイハイ受けるしか道がない
>>783 頭の悪そうな議論のすり替えですねw
君がPGなら論外だが、もし君がPGで無いなら、もうすこし先見の明を持った方がいい。
>>784 大手会社の自社開発に多い気がする。
若手は新卒のど素人、中堅も現場経験の無いど素人、上司は言わずもがな。
Cakeは一度php4対応を看板に掲げた以上 はそれを自分で下ろす訳にはいかないん じゃないの?だからこの先もずうーっと足 かせをつけられたまま。リードデベロッ パーが辞めてlithiumを立ち上げたのも多分 その辺が原因なんでしょ?
>>786 cakeのPHP4対応は過渡期だったから仕方無かったとは言え、
レガシーなシステムとの互換性を目的に作ったわけでは無いだろうからね。
lithiumが上手く行くといいね。
PHP4時代に金かけて作ったシステムを 今現在金欠な企業が使い続けるしかない場合もあるだろう
PHP4 を使い続けることによる脅威が現実のものになった時に被る 損害(金銭やら会社の評判やら)とPHP5に移行する際の費用を天秤に かけて、それでもなおPHP4を使い続ける方がコスト的に有利だと結論づけら れる根拠があるならそれでもいいんじゃないの。※見つかるとは思えないけど。
>>788 それでも実行環境はPHP5に更新するべき。
多少のコード修正は必要かもしれないが、PHP4のシステムをPHP5で動かすのは問題無い。(逆は無理だが)
数年前に脆弱性に対するサポートすら終っているPHP4を動かし続ける理由は無い。
実行環境さえPHP5に移行されていれば、
今後、追加修正する部分からPHP5を使えばいい。
という話。
PHP4で書く事にメリットは無い。
>>786 Cake2で、php4系を切りすてるみたいだけどね。
でも、php 5.2以降だから、namespaceは無しなんだね。
移行のし易さをとったってことかな?
4系を切り捨てたらあのORMはすこしはマシになるのかね。
そのcake2というのは現行1.3の次のバージョンとしてリリースされるのか?
だいたいこの先生き残りそうなFWは決まってきたな
時代に対応していかないとね
Yiiはもっと評価されるべき。
Yiiは日本で先陣を切る人が殆どいないのがなー かなり良くできてるけど、日本人英語だめな人多いしなw
他のフレームワークの方が良くできてるから今更yiiとかいらないだけ
では外国と違って日本には独自に優れたFrameworkが開発され好評を博しているということですね。
おっとethnaの悪口はそこまでだ
>>800 独自かどうかは関係無く、
Zend/Symphony/cake/CI/Ethna・・・ どれも日本のコミュニティがあり、ある程度盛り上がっている。
で、海外ではyii流行ってるの?w
みんな自分の信じた宗教にまい進すればいいんだよ
そうそう。特に技術に面倒臭がりは、自分が知っているものを極めればいいだけ。 新しいものを触りもせずに批判している暇はない。
>>802 海外でもyiiはそこそこじゃないかな。
はやっているとは言い難いけど注目はされてる。
優れた人の設計したFWなら後発のほうが出来がいいのは
当たり前だからね。
はじめてのフレームワークがyiiなんだけど、Giiみたいに自動でコード生成出来る機能って便利だね。 これは他のフレームワークでも普通にある機能なの?
むしろ無いとフレームワークなんてかったるくて使い物にならない
yiiはscaffoldの生成のツールとかwidgetの仕組みとかかなり良くできていると思うんだけどさ、モデルを FW内で定義したらそのモデルを実現するためのSQLをいちいち手で書かないといけないんだ。これが面倒。 fixtureの記述だって全部手作業。symfony/Doctrine はこれらを自動でやってくれくれるから楽。yamlに モデル定義を書けばSQLは自動生成だし、DBからリバースしてfixtureを作ってくれる。cakeやCIは 俺ほとんど知らないんだけどその辺どうなってんの?
scaffoldingは基本的に今時のframeworkなら実装されてる。 SQLを手で書く必要があるの意味は解らない。やり方間違ってない?
810 :
808 :2010/11/07(日) 16:48:59 ID:???
>>809 悪い、書き方が悪かった。言いたかったのはDBのテーブル定義のこと。モデル定義とは別にマニュアルでcreate tableしなくちゃいけないのよ > yii
そういうのはdbmigrations使えばいい yiiが面倒なのは他にあってだな…
scaffoldの差分更新とかはしてほしいよね。
cakeでも出来ないけど。
>>811 参考までに面倒な点教えてください。
ORMってどこまで使ってる? 複数テーブルをjoinして処理するような場合、無駄に重い(かつ設定画道そう)そうな印象なんだけど・・・ SQL書く事なんて殆ど無い感じ?
>>813 あくまでも自分の印象だけど
複数テーブルのJOINなんてはっきり言って関心の外という印象を受ける
典型的な親子関係については、頑張って抽象化してるのが多い
それに関しては、効率を考えなければ問題なく使える
でも、RDBに特化した、JOINとかUNIONとかそういうものを取り込んでいる
ORMってのはまだ無いような気がする
理想的な「オブジェクト」モデルまでしか考慮の範囲に無いってのが、
ORMのポリシーなんだろうな
だから、Symfonyのように、いざとなったらPDO使ってデータを配列で取ってこい、
あとからオブジェクトにしてやるから・・・というアプローチはむしろ必須だと思う
>>814 なるほど、One Object = One Table という実装や使い方が主流って感じですかね。
自分の場合は、以下のように
・1テーブルの1行をCRUD
・1テーブルの複数行をSELECT
程度にしか使っていなかったので、皆さんの意見を聞きたいです。
$table = new HogeTable();
$rowList = $table->fetch()
$row = $rowList->fetch();
$row = $table->createRow();
それはZendのアプローチなのかな? 主流というなら、、テーブルを抽象化するというよりはレコードを抽象化するのが主流な気がするけど いまだActiveRecordが強力な思想って感じで
>>816 うん。Zendメインに使ってるんだ。
未だにデザインパターンが良くわかってないんだけど、
ゲートウェイパターンとActiveRecordってPHPコードにするとどんな感じになるんだろ
ActiveRecordってのは曲者といえば曲者なのかも レコードの抽象化(save()メソッドなど)かと思えば、同じオブジェクトが find_by() みたいなデータ集合(テーブル?)の抽象化みたいな機能も持ってるし ぶっちゃけ、便利なのは認めるが、意味はよくわからん 俺だけかな
良くできてるけどルールに融通が利かないよね シーンナンバーである程度は変えられるけど
DoctrineのORMとしての出来はどんなもんなの?
融通がきいてしまったらフレームワークの利点が殺がれるって考え方もできるから そのあたりは一長一短だよなぁ
ところでフレームワークのnamespace対応ってどう思う? フルパスで呼び出す事が多いから、あまり利点を感じないんだが('A`; 同namespace内ならnamespaceを記述する必要が無いからコードが短くなるとは思うが、 フレームワークと同じnamespaceを使用する事はまず無いだろうし。 use構文で別名つけるにしても、別名自体が被ってしまうと厄介な事になるし。 区切り文字がバックスラッシュだから、文字列でクラス名指定する時面倒だし。 言語的に明確にスコープが区切られるのは良い事だとは思うけど、 ぶっちゃけ使いにくくない?
どう思うって言われてもな あるんだから、使って欲しいなってくらいか できればお手本を見せてくれるくらいの勢いで これで、一応フレームワークやライブラリのクラス名を気にせず こっち側でのクラス命名ができるようになった、ってくらいの認識 ZendFrameworkの命名規則で十分だったとか言っちゃだめなんだろうな1
極端な言い方をすれば、クラス名が名前空間の替わりだったPHPに、 今更名前空間を導入したところで、これまでの利用者の意識に大した 変革は無いだろうと むしろ、グローバル関数万歳な書き方をしていた人らへのインパクトの 方が大きいのではないかな 現実として言語仕様的にはある意味、やっと十数年前のPerl5のpackageに 追いついただけじゃないのかと思わないでもない もちろん、新規でPHPを始める人間にとっては全然違った意味がある 必要な変更だったとは思うけど
>>824 >ZendFrameworkの命名規則で十分だった
ぶっちゃけそうなんだよねw
区切り文字が「_」から「\」に変わって、多少構文が追加が追加されたイメージしか無いんよ。
>>825 あぁ・・・その発想は無かったわ。
確かにクラスに名前空間を含める風趣の内人には革命的かもしれないね。
ふむふむ・・・
今PEARやZENDの記法も次第にnamespaceに統合されるのかなぁ・・・
バックスラッシュは微妙だなぁw
827 :
nobodyさん :2010/11/10(水) 02:32:15 ID:2LA4cXC4
最初にPEARがあった。 なのに、CakePHPやSymfonyの命名規則がなんであんなに糞なのか理解不能
言語として推奨コード規約が欲しかったよな・・・残念
PHP自体、やっと後付けで最近汚いネームスペースがついたばかりの糞言語なのに、 なんでいまさら命名規則に文句を言うのか理解不能
830 :
nobodyさん :2010/11/10(水) 23:00:22 ID:2LA4cXC4
>>829 CakePHPやSymfonyの命名規則が糞すぎるから
PHPが糞言語とは思わない。糞だと思う言語を使うお前の職能は糞だと思うが。
>>830 >CakePHPやSymfonyの命名規則が糞すぎるから
>PHPが糞言語とは思わない。糞だと思う言語を使うお前の職能は糞だと思うが。
え?どういう理解力してんだお前?
頭悪すぎる上に妄想激しすぎだろ。
標準関数の命名規則がアレなのに糞言語だとは思わないんだな。 不思議。
834 :
nobodyさん :2010/11/11(木) 00:29:40 ID:IgwzUq/f
>>832 だから糞言語のスレで糞野郎のお前何してんの?
835 :
nobodyさん :2010/11/11(木) 01:13:35 ID:IgwzUq/f
PHPは糞まみれで前に進んでく感じがイイんじゃないか。
お前、俺をバキュームカーとまちがえてんじゃねえのか?
PHPはショボイけど、PHPを使わざるを得ない状況って言うのは多い。
泥臭い言語でもいいよ、必要があれば使うだけ でもやっぱり、namespaceのバックスラッシュは 日本語環境だとがっかりしちゃう(´・ω・`)
変な文字セット使ってるから
銭のマークに見えるのがいけないのじゃなくて、 それはエスケープ記号だって意識が先に立つのがどうしようもなく引っかかる
Rasmus Lerdorfが、組込み関数の引数の取り方が関数ごとにバラバラだけど別に良いじゃない?とか、 全然使わない関数が組込みに入ってるけど外そうとは思わない、みたいな事言ってるの聞いて、ああ、PHPってやっぱそういう言語なんだなって思った。
スレタイ読もうぜ
>>842 引数の順序がバラバラだが「目標を完遂するのに問題無い」と言っているし、
当人のインタビューwp読む限り、言語自体は暗に汚いと認めてるよねw
まぁ、それがメリットでもありデメリットでもあるんだと思う。
いきなり型宣言必須で、全関数メソッドがCamelCaseに変わり、内部言語はutf-8に統一しました!
とか言われたら誰も移行しないだろう(もしくは完成〜移行までに数年以上かかる)
そういう言語が必要ならそういう言語を使えばいい、って思想なんだろう。
UTF-16化は失敗しちゃったね
>>840 >>841 自分は正規表現書くときとか¥じゃないと書けない体になってしまったんだが。。
バックスラッシュだとパッと見/と区別しづらいし。
たまにオワタ\(^o^)/みたいになるのがいいんじゃないか
円記号+なにか でエスケープ文字って感じで目が覚えちゃってるから たまに正しいバックスラッシュ記号をみると逆に違和感覚えちゃうw
PHPも無名関数が使えるようになったり、だいぶマシになってきた。後はarray()のシンタックスシュガーだな。
まだそれを言うのか いい加減慣れろw どーしてもっていうなら、json_decodeでも使ってやがれ
名前空間だって、無名関数だって、ないならないでもプログラムが書けないわけではない。が、導入された。
array(1, 2, 3) が、 [1, 2, 3] と書けることにどれほどの意義があるのか 名前空間や無名関数とは大分重みが違う気がするんだが その辺を納得させられるだけの主張がないと、後回しというよりは考慮外のままだろ
そこでqiq・・・いやなんでもない
長いことやってるとarrayのタイピング量はわりとうざったい
文字列リテラルを考慮してない名前空間もだが 糞仕様はすぐ取り込むのに無意味な所で保守的 関数スタイルじゃなければならない理由こそ知りたい せっかくパッチを書いてくれてる人が居ても報われなくね
いや、〜〜は導入されたのにとか言っても、 いらないものはいらないってだけだろ そのパッチを書いた人にしたって、取り込んだ方がいい理由ってのを 全然まったく説明できてないだけなんじゃないか?
だから、必要な理由をだな・・・ それが好みの問題なら、反応はギャンブルみたいなもんだろ
>>859 納得がいく理由があれば通ると思うだろ?
そうじゃないんだよ、大多数の人が”いる”と思っててもスルーされるんだよ
大規模プロジェクトはそういうもの
そもそもphpなんてコアメンバの中にまでマルチバイト対応はいらないと思ってる人がいるくらいだからな
phpを語るスレになっとる
正直すまんかった
kohanaって結構document揃ってるのな 和訳してる人いないのかな?
だって、PerlでもRubyでもPythonでもJavaでもCでもJSでも、みんな()とか{}とか[]で配列初期化出来るから名。 PHPだけarray()って5文字も多い。これを変だと思わないのはどういう了見かと思う。
無名クラスが使えるようにして欲しいのと、newから直接メソッド呼べるようになって欲しい。 特に後者。
>>865 後者の方は、インスタンスを返すクラスメソッドを用意すれば現状でも可能では?
singletonとは区別が付くようにしておいた方がいいだろうけど。
>>866 標準クラスとかライブラリ、フレームワークのクラスとかだと・・・
むーなるほど。同感は同感。
>>869 http://marc.info/?r=1&w=2&q=b&l=php-internals&s=Autoboxing 小泉「オートボクシングはお餅でしょうか」
ML「えっ」
小泉「まだお餅になってないということでしょうか」
ML「えっ」
小泉「えっ」
ML「変化するってことですか」
小泉「new Foo()->bar()->baz(); とか array(1, 2, 3)->filter(function ($v) { return $v > 1; })->sum() == 5 とか書けます」
ML「そうなんだすごい」
デミ「なにそれこわい」
小泉「えっ」
ML「えっ」
デミ「遅いし構文とかリークとか怖いし何より俺の書いたオプティマイザが役に立たないし」
小泉「えっ」
ML「えっ」
Zendが難しすぎてこちらに来た どうすればいいですか? 教えてくださいフレワク先生
>>871 どこが難しい?
Zend_Toolでプロジェクト作ってそれ改造してくといいと思う。
この小泉って人、mbstringのメンテナだよね。ブログとか勉強会での発言たまに見るけど、全然PHPに愛着ないよね。↑みたいなの見ると、何となく分かるけど。 mapとかブロック付きメソッドとか使えると便利なのにね。
>>872 PHPをコマンドラインで扱えない人種も多々いるんだよ。察してやれ。
>>873 もっとパッチ作ってる人も
phpによる開発を全くしたことがなく、今後もやるつもりはない
仕事でCを使っているのでパッチを書けるから書いている
こういうスタンスで有名
別に愛着とかどうでもいいと俺は思うけどね
ずっとmbstringメンテナンスしてくれればいいけどね。
mbstringsとかコアにいれる必要ある? 入出力でiconvフィルタかけられて基本UTF-8でいいよ、もう。 バックスラッシュとかチルダでバッドノウハウ的なのが残るだろうけど。
mb_convert_kanaとか便利すぎて他のスクリプト言語(Ruby,Python)がいくら文法的にイケてても 日本語の扱いの際に霞んで見える・・・ ある意味日本語でPHPを扱う時の実用関数としては神レベル
他の言語にそういうライブラリないの?
ライブラリを探せばあるかも知れないけど、PHPのmbstringファミリーほど日本語に特化したライブラリってなかなかないと思う。 他の言語は内部エンコーディングがユニコードベースになってるけど、実用性という意味じゃPHPのmbstringは非常に優れてるね。 まあ、完全に関数ベースで、すべてmb_xxxって書き換えなきゃ行けないのは全然格好良くはないけどね。
MbString::convertKana($str, 'KV', 'utf-8') とか書けるといいのか? $mbstring = new MbString($str, 'utf-8'); $str = $mbstring->convertKana('KV'); とか?面倒くさいだけかもという気もしなくはない
> $mbstring = new MbString($str, 'utf-8'); > $str = $mbstring->convertKana('KV'); 一応、チェインするなら意味はあるかも $mbstring->convertKana('KV')->substr(0, 3)->convertEncoding('sjis-win') でも、そうするとこうなるんだきっと $str = $mbstring->convertKana('KV')->substr(0, 3)->convertEncoding('sjis-win')->toString();
なげえ
PHPにオブジェクト志向なんて不要かも寝
>>882 全部のメソッド名をconvertXXX()にしようとするのは、名前空間がなくてグローバルに全部の関数をつっこむPHP脳。
<? $str->setEncoder(function ($v) { return isMobilePhone() ? mb_convert_kana($v, 'ak', 'utf-8') : $v; }); ?> <html> <?= $str ?> </html> とか。
>>881 >>882 関数思考でクラス化してもメリットは薄いと思う。
変換部分をラップして、変数や配列に対して処理を使い回せると便利な気がする。
$mb = MbString::getInstance()
->setKanaFilter('KV')
->setOutputEncoding('sjis-win');
$string = $mb->encode($string);
$array = $mb->encode($array);
ていうかStringクラスが欲しい。
あとMapとList。
$str = new String('A&B'); print $str->escape(); // A&B print $str->escape()->escape(); // A&B print $str->escape()->escape()->unescape(); // A&B とかな。
↑うまく行かなかった。 $str = new String('A&B'); print $str->escape(); // A&amp;B print $str->escape()->escape(); // A&amp;B print $str->escape()->escape()->unescape(); // A&B
>>892 class String {
public $value = "";
public function __construct($string) { $this->value = $string; }
public function escape() { $this->value = htmlspecialchars($this->value); return $this;}
public function unescape() { $this->value = htmlspecialchars_decode($this->value); return $this;}
public function __toString(){ return $this->value; }
}
利便性を考慮すればする程重くなりそうだしメリット無さそうだけど。
PHPの仮コードで書いたらコピーが増えるだけにみえるけど 内部的にはストリームでつながる実装にするだろうし 見た目も性能もよくなりそう。
見た目は好みの問題。 性能に関しては確実に落ちる。
ひとくちにescapeといってもhtmlだったりsqlだったりshellだったりするわけで、 それをStringに直接実装しちゃうのはなんか違うんじゃないのかという気がした
$str_list = array(); $str_list[] = new String_Html; $str_list[] = new String_Sql; ...... foreach ($str_list as $str) { print $str->escape(); }
>>893 ちょっと意図が違う。
public function __construct($string) { $this->value = $string; $this->isEscaped = false; }
public function escape() { if (!$this->isEscaped) { $this->value = htmlspecialchars($this->value); $this->isEscaped = true }; return $this;}
public function unescape() { if ($this->isEscaped) { $this->value = htmlspecialchars_decode($this->value); $this->isEscaped = false; }; return $this;}
かな?
エスケープしてるかしてないか分からなくても、とりあえずエスケープしとくっていう使い方。
>>897 単にエスケープ形式を変えたいだけなら、個別クラスにする必要性なくね?
(String_HtmlとString_Sqlに構文バリデーションが含まれるなら別だろうけど)
$str_list[] = String::getInstance('<html></html>')->setEscapeType('HTML');
$str_list[] = String::getInstance('SELECT * FROM hoge')->setEscapeType('SQL');
>>898 それだとescape以外のメソッド実装したり、二重エスケープしたい時とか面倒じゃね?
単に出力時に確実にescapeしたいだけなら、toString内にescape処理を実装する方が正しい気がする。
2重エスケープは特殊なケースとして明示的に行った方が良いだろう。 String_Htmlクラスではデフォルトでエスケープしてしまうのも手ではある。テンプレートエンジンのエスケープ処理でそういう事をやってるのはよくある。 いずれにせよエスケープ状態を表すフラグを持たせた方が良い。 そうでなければ、その2重エスケープだとかその他の特殊な処理を行うのが難しくなる。 そういうフラグを持たせられる事こそがプリミティブ型をオブジェクト型にするメリットだから。
クラスの実装をどうするかは、ここでは問題ではない。文字列をオブジェクト型にする事にどういう意味があるか?が問題。
>>900 >いずれにせよエスケープ状態を表すフラグを持たせた方が良い。
は解るが、isEscapedの判定をescapeメソッド内で行うべきでは無いかな、
if (!$string->isEscaped) $string->escape();
と明示的にエスケープする方が美しい。
2重エスケープはほんの一例だよ。
lengthとかmatchとかconvertEncodingとか、文字列をオブジェクト的に扱うメソッドを実装する時に、
エスケープされてるか否かでメソッドの挙動が変わるのはデメリットの方が多い気がするな
>>901 ●メリット
・流れるようなインターフェースが実装出来る
・PDT等のコード補完と相性が良い
・引数タイプヒンティングが行える
●デメリット
・文字列を引数とする標準関数との親和性が下がる
・実装&実行コストの増加
ってところかね
透過的にするならこんな感じかな。うーんクセ強いな class HtmlString { public $org = ""; public function __construct($str) { $this->org = ($str instanceof HtmlString) ? $str->org : $str; } public function __toString() { return htmlspecialchars($this->org); } } function h($str) { return new HtmlString($str); } $str1 = h("<a>"); $str2 = h($str1); echo $str1, $str2;
>>904 クラス名が紛らわしいな・・・文字列操作で無く、エスケープを主体にしたクラスだよね。
HtmlStringじゃなくてEscapedHtmlという感じの方がしっくりくるな。
てか大抵のシステムではエスケープはビューの出力時に一度行えば良いはずなので、
わざわざ文字列をクラス化するメリットは薄い気がするわ。
PHPってJakartaCommonsみたいなプロジェクトないの?
まあ、実装はケースバイケースで適切にすればいいんだ。拡張性を考えるなら、処理を別メソッドに分割した方が良いし、速度を考えるなら、出来るだけメソッド呼出しは減らした方が良い。
エスケープ済みフラグを持たせるのは、テンプレートの中からテンプレートを呼び出すが何階層あるか分からないとか、そういうケースで効果ある。
文字列をオブジェクトにラップしてデフォルトでエスケープするのは、PerlのText::Xslateとかテンプレートエンジンではよくあって、
PHPはあまり詳しくないど、多分PHPでも似たような事やってるのは探せばあると思う。
エスケープし損なうのは絶対避けたいから。
例えば、
>>886 に書いた、
$str->setEncoder(function ($v) { return isMobilePhone() ? mb_convert_kana($v, 'ak', 'utf-8') : $v; });
の'utf-8'は未定義の場合にmb_detect_encoding()でエンコーディングを探すようにするけれど、これをキャッシュしておけば以降の処理でコストダウンになる。
こういうのがオブジェクト型にするメリットだと思う。
もっとも、実際にこういうのやろうと思っても、PHPは演算子オーバーロード出来ないし、永続化出来ないmod_phpだと速度的にダメすぎるだろうな。
そういうわけで、mbstringは実用本位なPHPによく合ってると思う。
>>908 >>886 の例、PHPではStringクラスじゃなくてTemplateEngineクラスに実装する風潮があるね。
(実際多くのテンプレートエンジンはそうなっている)
ていうかビューで扱う全ての変数をStringオブジェクトに変換しないと結局エスケープ漏れが発生しちゃわないか?w
こういう流れ好きだわw
-> こんなのわけわかんないんだよね・3・ 難しいよ・3・ ちね
912 :
nobodyさん :2010/11/30(火) 05:39:49 ID:+I0UUEzG
うるせえ!だまってやれ
一概に言っても ・基底フレームワーク ・アプリケーションフレームワーク とあるからなぁ、一般的にはオープンソースのフレームワークを基底に、独自のフレームワーク(っぽい実装)を作るよね? その独自部分のノウハウとかテクニックを聞きたいです先輩!
Cakeみたいなフルスタックをベースにすると、ビジネスロジック以外の独自な実装をする余地がほぼ無いです。 むしろビジネスロジック以外で独自色を出そうとするとメンテ性が悪くなり謎の挙動不審に陥りハマりまくる。 ただし、これは多分、SymfonyやCIも同様。 (・∀・)イイ!! は知らん。 ちいたんとかは、よく知らんが基本設計がよければ俺色に染め甲斐がありそうだ。 Zend FWに関しては、みんなどんな風に使ってるのかよくわからん。 Zend_ToolをベースにしてオレオレFWを作ってるのか、 オレオレFW用ライブラリ集として活用してるのか、 Zend_Toolをベースに完全にZend謹製のものをつかってZend準拠なやりかたでZend Wayしてるのか。
>>914 独自色というか、FWの仕様と微妙に合わない実装を強いられた時に、
独自クラスでラップする事はよくあると思うんよ。
すると
>むしろビジネスロジック以外で独自色を出そうとするとメンテ性が悪くなり謎の挙動不審に陥りハマりまくる。
となるわけで・・・ここらへんのうまい落としどころとかテクニックが合ったらいいなぁと思ったのさ。
View周り以外で、既存のものとすりあわないものっていうと、どういうのがあるだろう
CakePHPの可読性の悪さにビックリしたよ。 PEARやZend Frameworkのコードに慣れているからかもしれないが、 CakePHPを使って、まともなコードのWebアプリは作れない。 よくあんなのが人気あるのか不思議だ。 CakePHPには、ソースコードの良し悪しが分からないド素人しか食いつかないんじゃないかなぁ。 てわけで、俺はZFに一票。
918 :
914 :2010/12/02(木) 10:33:51 ID:???
>>917 俺はCake厨のド素人なんですが、
ソースが醜い&設計も微妙な部分があるというのには同意で、
でもZend Frameworkをどんな風に使ってるのか(使う事が推奨されてるのか)
>>914 でも書いたように全然分からんのです。
ActiveRecordあるんかなとか、そういうのも含めて・・・
まあググればいいんでしょうけど、Zend Frameworkをスゲエ便利に使ってますって感じの
記事を読んだ事が無い・・・。
最初は命名ルールの縛りから逆にチーム開発には有用だしと半分我慢しつつ使ってきたけど array地獄でIDEの補助も受けられないし、人間の負担が変に大きすぎる。
素人なんだけど、arrayはミスがあっても気づかなくてすごく時間を無駄にする。 けど、一気に設定を流し込む場合にこれ以外の良い方法はあるの?
別形式で書いて機械的に変換掛ける 俺俺バリデーターを作って実装前にチェック掛ける PHPをやめる
ZFは自分好みに拡張してなんぼじゃないかな。 取捨選択しやすくて拡張の土台として都合がいい。 その分、素体のまま開発始めようとした場合のご利益は少ないと思う。 あとはソース見てクラス設計の参考に使うのも結構いいかも
基底クラス郡
>>917 可読性が悪い理由は簡単で
互換性を重視しているからだよ。
PHP4に対応するために、あえてPHP5の機能を
使わないで作られている。
いまどきPHP4なんてと思うかもしれないが、
CakePHPが人気が出たときはPHP4のサポートは終了しておらず、
PHP5への移行期だったから人気が出た。
いまだに古いRHELとかPHP4を搭載したディストリが
サポート期間中だったりする。
PHP5の機能を使わなくたって、可読性の良い コードは書けると思う。
フレームワークの良し悪しは好みかもしれんが、 ZendFrameworkの明確なコード規約は素晴らしいと思う。 冗長と感じるかもしれないが、IDEとの親和性が抜群に良いのでチーム開発する上では必須。
>>927 同意です。
ところで、
>> IDEとの親和性が抜群に良い
とのことですが、何をお使いですか?
NetBeans? PDT?
参考までに教えてください。
ZFのコーディングルールと言うより単にphpDocの話じゃなくて?
>>928 PDT2.2をメインにしています。
NetBeansより重いですが、コード補完機能とコphpDoc生成機能がより協力な感じがあります。
>>929 phpDocの書き方を含めて、各種命名規約、インデント改行規約、PHP閉じタグ無し等が名言されてるんよ。
改行とかの規約はPEARにも明記されてるし、 べつにCakeにないからどうという話じゃないと思う レイヤーが違うというか
Cakeでいえば App::importで魔法的にパッケージ解決するところが逆に癌。 コントローラへの自動bindがあるから同名のModelとComponentも回避しないといけないし。
>>931 誰もCakeを否定していないし、何故PEARが出てくる。
>>934 その4つの規約にも、それぞれメリットデメリットがあるし、規約も含めてのフレームワークだと思うよ。
個人的には最も枯れているPEAR記法をベースにしたZend規約がベターで、
PDT(ZendStudio)との親和性も高いと感じたのさ。
相性の悪い規約とIDEってあるの? 規約やIDEの評価基準に使いたいから、純粋に知りたい
実行時に動的にバインドする系のはヒントが出ないよね
しいて言えばPEAR&Zend形式はアンダースコア区切りの疑似ネームスペースを採用しているので、 パッケージ名が被る心配はほぼ無いってのが強み。 cakeはPHP4コード&マジックメソッド実装が多めで補完が弱い。 Symfonyは2.0でZend風の命名規約に移行するし、 Twig等の周辺ライブラリは既にZend形式になっている。
939 :
691 :2010/12/07(火) 03:42:12 ID:???
>>938 Zend形式というかPEAR形式が強いよね。
CakeはPEARとの相性が最悪。
940 :
nobodyさん :2010/12/08(水) 00:24:03 ID:4EtmohlD
なんでnamespaceが実装された昨今 Zend風の命名規約にするかなぁ。
>>970 5.2を完全に切り捨てるのはまだ早いからかと。
あと、PHPのnamespaceはお世辞にも使いやすいとは言えない。
(PEAR&Zend形式から乗り換えるメリットがほっとんど無い)
まず、
・クラスの完全修飾にバックスラッシュが入る
→ 文字列にクラス名入れる時に面倒がおこる
・名前解決が無駄に複雑
→ 同ネームスペース内であれば、記述が楽になるかもしれんが、
大抵の場合は \ で始まる絶対パスで記述する事になる。
5.3の他の機能は素晴らしいと思うが、
Zend形式でなく、namespaceを使う明確なメリットを教えて欲しい。
正直PHPのnamespaceは流行らんと思う
バックスラッシュはエスケープにも使うからなぁ
やっぱり型あり言語がいいよ
クラス内のメソッド定義で、public を省略してもpublicになるのが 許せん。 省略したら普通privateだろ〜
普通って何? ていうか普通は省略しない。
947 :
914 :2010/12/09(木) 19:18:57 ID:???
>>945 PHP4との互換性のためだから仕方ない
まだPHP4対応で書かなきゃいけない可哀想な人なんだ察しろよ
>>947 Javaは省略したらprivateにはならないよ。
951 :
914 :2010/12/10(金) 00:02:32 ID:???
いんたーなる ねーむすぺーすのないPHPとしては、全部が同じ場所にいるようなもんだから ある意味あってるという見方もできるな
じゃあどんなnamespaceだったら良かったと思うのよ?
>>953 言語仕様的にネームスペースは不要だったかと。
接頭子でネームスペースの役割は担えてるし、JavaScript等も同じような方法でnamespaceを実装してるし・・・
ネイティブにnamespaceを実装するとコンパイラとの相性は良いのかもしれんけどね、PHPでは不要だよね。
また Hoge_Moge_ClassName と書いていたクラスが \Hoge\Moge\ClassName と名称変更されるのだが、
バックスラッシュを区切り文字に使ってしまうデメリットは結構あると思う。
同ネームスペース内なら、ClassNameを直接参照出来るというメリットはあるが、
そんな場面は滅多に無いし use構文で別名付けちゃうと、今度は他のクラス名と被る可能性が出てくるので
結果的に、フルパスでクラス名を記述する事になる。
となると、何の為に 5.2以下を切り捨ててまでnamespaceを使うのか?という事になる。
>>945 お前の言う普通はマイナーすぎ
普通は省略したらpublic
逆に考えるんだ PHP5.3を普通と考えて 他の言語環境を「普通」とどれだけかけ離れているか 語るくらいの図太さと厚顔さがPHPerには必要だ
>>955 普通ってなんだよ
Javaなら省略したらdefaultだ
>>954 なんで今まで散々Perlをパクりまくったのに
ネームスペースはパクらかなったのかと。
まあ、PHPの場合、ほとんどウェブ専用で、ウェブアプリケーションフレームワークはフルスタックのばかりだから、外部ライブラリを読み込む機会がないというのはあるかも。 でも、ネームスペースが不要とかって事はありえない。 JSなんかはネームスペースかないせいで$とかぶつかりまくってる。
コードの再利用、ライブラリをつかってこねくり回すことが主体になってきた昨今だと ネームスペースの重要性は切り捨てれるようなもんじゃないからな 小規模なものなら問題ないけど、どうしてもつかいたいライブラリ同士の 名前がぶつかったりした日にゃ、めんどくさいことになる
>>959 JavasSctiprtはネームスペースあるだろ。
ネームスペースという機能自体はないが、
規約レベルではるがネームスペースはある。
そしてそれはPHPのネームスペースより余程エレガント。
>>959 >>960 ネームスペースという概念は必須だと思うが、
それはPEAR規約で既に実現されている。
バックスラッシュで無理矢理ネイティブ実装されたnamespaceを使うメリットは薄いって話。
一度PHP5.3のnamespaceを使ってごらん、PHP5.2を切り捨ててまで使いたいとは思えないだろうから。
>>962 でもPHPの構文として用意されたネームスペースを使わずに
規約として用意されたネームスペースもどきを使うようじゃ駄目だ。
今後スタンダードなものとして使うことはできんな。
symfonyのようなPHPを代表するようなFWなら尚更だ。
PHP生みの親 「日本ではバックスラッシュが\マークなんだってなwww」
>>963 頭硬すぎ。
その、「規約として用意されたネームスペースもどきを使うようじゃ駄目」な理由を述べてくれよ。
単に新しいもの=素晴らしいとでも思ってるの?
いくら構文として用意されていても、
規約を守らずにnamespaceを使ってしまっては意味が無いし、
use文によるエイリアスとか、潜在的なバグが増える事も想定される。
ネームスペースの概念は必須だが、PHP5.3のnamespace実装はお粗末すぎる。
5.2以下(既存FWユーザ)を切り捨ててまで移行するモノでは無いかな。
どうなったら移行するの?
>>966 たらればの話はいい。現状、メリットの無いモノに移行する必要は無い。
>>965 機能としてネームスペースが用意されているのに
規約としてのネームスペースを使うということの気持ち悪さ。
お前は保守的なんだよ。
ところでなんでお前は規約としてのネームスペースにこだわるの?
機能として5.3からネームスペースが正式に実装されたんだから
黙って使えよ能無し
別にそこで止まりたい人はそれでいいんじゃね? 使った事のあるフレームワークはみな移行してるんで俺は移行するだけ 置いていかれる人の事なんてどうでも良いよ いつの世もそう言うのんびり屋な人達はいるしどうぞご勝手にって感じだわな 言い訳考えるぐらいならさっさと過去の資産の為のコンバータ書いた方がマシ 俺はね
>>964 バックスラッシュで表示されてるけど??
自分の環境が問題
ここはネームスペースのスレですか?
>>968 >>969 ネームスペースなんて実装じゃなく規約の問題。
ネイティブにnamespace構文が存在したとしても、命名規約が統制されなければ意味は無い。
(これはuse構文によりさらにややこしくなってるし)
また、保守的になってるつもりは無いよ。
メインはPHP5.3開発に移行していて、無名関数とか遅延バインディングとか便利だと思ってるし、
5.4のGC含めて久しぶりにPHPコードを書きまくってる。
ただし、namespaceだけは判断が微妙で、
例えば5.2以下で実装出来るロジックでも、
namespace配下に置くことで動作しなくなるというデメリットがきつい。
Redhatを代表とするサーバ系OSには今だPHP5.3はバンドルされてないし、
完全に普及するには年単位の時間がかかると思われ。
RHEL 6 / CentOS 6 では PHP 5.3 が標準リポジトリに入るよー。 PHPのnamespaceは接頭辞が省略できるだけでシンボルテーブルまでは分離されないから 名前空間というのは名前だけで、メリットが少ないのは否めないね。
>>970 言語としてネームスペースの推奨規約が存在する(ActionScript3とか)は、
ディレクトリやファイル名を含めて綺麗に纏まるから、
擬似的に実装するより遙かに便利だとは思う。
PHP5.3のネームスペースは肝心の規約が抜けているので、
「単にアンダースコア区切りだったものをバックスラッシュに変えました。」
程度の効力しかない。
言語仕様以上の規約があるのか? あんたの言う規約は自分の都合の良い保守的な規約じゃん 新しいものを追えない技量なら素直にそう言え 技量がないとは失敗してもバックできないのも含む そのレベルならゴチャゴチャ言わずに後から俺等の背中追ってこいよ
>>976 言語仕様以上の規約は無いかもね。
しかしPHPはその言語仕様の規約がお粗末だって話だろ。
「とりあえずnamespace構文作ったから使ってね。クラス名とかディレクトリとかファイル構成は・・・適当でいいよw」
って状況。
新しい物が本当に良い物かどうか判断も出来ない、盲目的な君の背中は遠すぎて追えないわ。
精々未来に生きて失敗事例を沢山こしらえておくれ。
多数の名のある識者が決めた事>>>>>>>>>>分厚く高い壁>>>>
>>977 の考え
なんだか老害になる瞬間を見た気がする… こうやってドンドン取り残されていくんだろうなぁ 俺も気をつけよ
・・・PHPのnamespaceの紆余曲折っぷりを知らないのかw ゆとりって怖いな
あはい
5.2系の更新がラストだって言われてる時にネームスペースの話かよ 未だに対応出来てないとか遅れてるにも程があるだろjk
今北産業
>>984 愚者:僕がPHP5.3系に移行するまで待ってよぉ〜
識者:急ぐ必要はないし後から来れば?
愚者:ふざけんあはwせd
>>982 頭のいい人ばかりでは無いって事さ。
世の中言い訳ばかりして手を動かさない奴はどこにでもいるだろう?
そゆことなのさ。
SEだろうが何だろうが最新技術を追えない時点で終わってるだろ 最新という競争力のあるワードを使えないSEは今の世の中生き残れないわな
そうはいうがビルド出来ないが為に脆弱性を持った環境でサービス動かしてる奴が殆どなんだぜ… そう言う輩に最新を追えというのは無理じゃなかろうか…
>>988 枯れきってバグや脆弱性がほぼ埋まったPHP5.2のコードが稼働している。
それらのPHP5.3への移行リスクやマネージメントを考えた事があるか?
「最新という競争力のあるワード」ねーよw
少なくともPHP5.2とPHP5.3に競争力は無い。
それでも5.3への対応は必要だと考えているよ。
でもnamespace化する事と5.3化する事は別レイヤーの話だ。
今までの規約で5.3へ移行する事も出来るし、過去の資産はそれでいいと思っている。
namespaceが最新技術とか 追っかけるとか そういう言い回しはなんか違うと思うけどなあ
なんでこいつは名前空間とパスを同一視してるの? こんなんだからPHP使いはレベルが低いとか言われるんだよ…
>>993 パス=クラス名への絶対修飾子って意味ね。
Zend_Hoge_Moge と書くのも \Zned\Hoge\Moge と書くのも同じだし、
このように絶対パスで書かないとクラス衝突は防げない。
となると本来目標にかかげていた、冗長なクラス名の廃止はどうなったのかと・・・
明らかに設計ミスだろ。
? その目的の為の名前空間でありそれは達成されてるわけだが? 5.2を切り捨てて対応してるフレームワークなりなんなりみてみろよ 綺麗に切り分けられクラス名は短くなってる
>>991 だよね。
むしろ、いまさら実装されましても、っていう思いしかないわ。
>>995 されてねーよ。
定義側は省略形で書けるかもしれんが、
実際に使用する側はフルパスで書かないといかんだろ。
打開策として use で別名エイリアスが付けられるが、
エイリアスが他クラスと被る可能性があるという本末転倒っぷり。
それならエイリアスなんか作らず
$className = 'Hoge\Moge\Class';
$class = new $className;
と書く方が利口。
どちらにせよ、当初の目的は果たせていない。
使いたい奴は使えばいい Javaで言えばジェネリック拒否 C#で言えばラムダやLINQ拒否 オブジェクト指向拒否に関数型言語拒否と世の中前を向かない人間なんてザラにいる 一々そう言う奴等を説き伏せてたら時間がいくらあっても足りないでしょ
そこでラムダを持ち出すあたりがアホだなあ
>>997 頼むから他の言語の名前空間を使用してから言ってくれ…
エイリアスが他クラスとかぶる可能性とか何を言ってるんだと言わざるを得ない
jsですらjqueryやらprototypeやら他のライブラリつかって名前空間を表現しようって風潮なのにどんだけ取り残されてるんだよ
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。