【PHP】PHPフレームワーク総合スレ15

PHPでアスペクト指向フレームワークはありますか？
「下らなぇ」スレで聞いても返答はありませんでした。

Seasar2.PHPかSymfony2

下らなぇスレを責任持って立てろ

アスペルガー

上の方で学習コストの話があるけどさ、
学習コストの低いフレームワークを選択して足りない機能がでてきた場合は
自分でコーディングすることになるわけじゃん？

ある程度スキルのある人なら問題ないだろうけど、初心者が調子乗って
拡張機能つくってもろくなコードにはならんぜ。保守性・安全性の面で。

大抵はあとで別の人間が書き直すハメになって、
最初からちゃんとしたフレームワークつかっておけばよかったね
ってなるというおはなし

連投そまそ

でも作る経験は財産になるから難しい

アスペクト指向プログラミングはどうしていますか？

でも機能豊富なゴテゴテしたフレームワークを選択しても
スキルの低い人は、理解できない使いこなせないで
結果ものすごいものが出来上がるというのも
よくあるおなはしなわけで。

機能豊富なフレームワークで、そのご自慢の機能使おうとしたら
まともに動かなくて、結局自分で書く羽目になるというオチ

俺はCakePHPでそれくらった

1. (自分のスキルがしょぼいせいで)まともに動か(せ)なくて
2. (自分の使ってるサーバーがしょぼいせいで)まともに動かなくて
3. (ご自慢の機能が実は自分の期待よりしょぼかったせいで)まともに動かなくて

で？

感覚的な学習コストの序列ってどんな感じかね？
個人的には

code igniter << Yii < Cake PHP < Symfony

と言う感じだが、最初に触ったのがSymfonyだったから思い出補正あると思う

どういう序列なんだ？Symfonyが一番簡単って意味か？

コスト低 <- ->コスト高　ね

Cake PHPやSymfony って情報量多いし、学習コスト低いと思うんだが。

ciなんて作りが雑過ぎて、その分をフォローするための学習コストが多すぎる

オレオレと変わらないからな

他人が作ったオレオレフレームワークだな。

学習コストねぇ
有用なら高くても使うがね

学習コストは人によって違うからね。
有用でも情報量が少なければ理解するまで時間がかかるし、
そう言う面で学習コストがかかるならマイナスだよ

何をもって有用とする？

それも人それぞれでしょ。
個人や少人数でやるなら好みや感触で決めてもいいような気がするけど
多人数チームでやる場合はほんと悩ましいよね・・・

そもそもPHP自体が、使いもしない要らない機能だらけで、有用ではない

ガラパゴス化している日本人にピッタリじゃないか

検索エンジン等、動的部分はフレームワークで、
会社概要等、静的な部分CMSにまかせるってどうなんでしょうか

作り方が異なるファイルが混雑するとややこしくなるよ。
静的な部分もフレームワークで作った方が良いと思う

プログラマが更新するか、
デザイナーも関わるか

デザイナーが関わるのは無理だよ。むしろ関わらせちゃ行けない。

デザイナーもグラフィカルに編集できるものを目指してるんしゃないのか

CMSがフレームワークに置き換わる日
http://blogs.itmedia.co.jp/yoshimasa/2011/06/cms-f1f8.html

今の時代、フレームワークを土台にして作るのではなく、
CMSを土台につくったほうがいいんですかね。
フレームワークも便利ですけど
RSS発行とか、フォーム作成とか
自分でプログラム組まないとだめじゃないですか。

フレームワークでは数時間かかるRSS発行処理作成とか
CMSでは数クリックでできるし
処理されたデータを、どう煮るか焼くかは
CMSもフレームワークも変わらないし。

ただ
>>393さん
みたいに、高度な改変となるとCMSは
プログラムの解析が大変という意見もありますし、
何を作るかによってかわってくるんでしょうが
フレームワークに自作関数や、自作ライブラリを相当作りためてでもいないかぎり
ＣＭＳを使ったほうが効率がいいんですかね。

プログラミングができない人から見るとそうなのかもね。俺は全く別物だと思うけど。
CMSで事足りるならそれでいいのではないかと。要件を満たすかどうかの問題。

フレームワークは高機能で便利な魔法のツール、みたいに思っているのかもしれないけど
それ以上に大事なのは、制限やルールといった枠組みを与えることで、
人それぞれバラバラになりがちな開発の手法や方向性を統一できること。

って誰かえらいひとが言ってたような気がする。

表示系はなんとかなるけど、
DBから取り出す条件設定の制御が面倒な事多くね？
クエリ直接書かせろ！みたいな…

官公庁はCMSが主流

オリジナル要素が高くなければCMSで良いかもね

CMSが勝手のいいフレームワークで作られていれば良い

WordPressやEC-CUBEがが使いやすいMVCフレームワークで作られてればよかったのに…と何度思ったことか
カスタマイズつらいです…

ワープレって、MVCじゃないのか。
MVCじゃなかったらプラグインひとつ作るのも
かなり手間かかりそうなんだが・・・。

違うね。共通ファイルは分けてるけど、細かくビュー分けはしていない

EC-CUBEは独自フレームワークだけど、
こちらも複雑すぎてどこがどこにあるかわかりづらい

複雑ってのは俗に言うスパゲッティってことだな

そうそう。EC-CUBEは色んな開発者が共同で作ってるらしいから
どうしてもスパゲティになるよね

EC-CUBEはソースひどいよな。トランザクションとかちゃんとしてなさそうだし、いくらでも穴がありそう。

// これで勘弁してください…
的なコメントが書いてあったりするし。ジョーク系のサイトでよく似たネタ見るけどオープンソースでは初めて見たわ。

ソースの具体例は？

>>463
＞色んな開発者が共同で作ってるらしいからどうしてもスパゲティになるよね
いや、その理屈はおかしい

>>466
おかしくないよ。だって規約が統一してないんだから。
開発者が違うって言っても社内じゃなくて、他社って意味だし。

スパゲティの意味をまずわかってください

>>467
外部の異なる組織からフリーランスまでさまざまな開発者が
参加して作ってるオープンソースソフトなんて山ほどあるんだが
さすがにそれらのほぼ全てがスパゲティだなんて話は聞かないよ

>>469
ほぼ全てのOSSの話しじゃなくて、あくまでEC-CUBEの話しな

どうしてもスパゲティになる
を他のソフトにも適用するのはやめたまえ

なんで他のOSSが大丈夫で、EC-CUBEだけ
スパゲティになるんだよｗ

いやぁ、WordPressのごちゃっぷりは良いレベルよー

PHP自体がスパゲティだよ。
標準関数の首尾一貫性の無さはスゴすぎ！

>>472
普通、OSSって特定のグループ・会社が作ってないか？
OpenPNEなら手島屋って会社が作ってるし、
phpBBも海外のグループが作ってたはず。

一方、Wordpressは開発者はいるけど
プラグインで拡張していくから開発者も違うし、一貫性がない

すべてのOSSを調べてから言えよハゲ

OpenPNEもひでえソースだったなあ

OpenPNEのカスタマイズは断念したな

逆に、このフレームワークは美しいソースだったなぁってのはないの？

symfony2
ソースの見てくれの代わりに使い勝手が犠牲になったけど。

PHP自体が美しくない

そもそも「美しさ」の感じ方は個人差によるからな

EC-CUBEは番人に共通する醜さだけど

EC-CUBEはあんなソースでそこそこ動いちゃってるのが不思議なくらいだな

管理とかちゃんとなってない会社なんだろうな
スキルの低いエンジニアが会社の床で寝ながら泥沼のようにして作った印象
あのスタイルで書いたコードのデバッグをやりきるには大変な根性が要るはず

俺の見立てではわざとやっていると思う。
OpenPNEもそうだけど、わざとソースを複雑にして
有償サポートを狙っている気がする

※あくまで個人の感想です

PHPが汚いとえば
文字コードを変換する
mb_convert_encoding　の配列版はないかいな思って調べたら
mb_convert_variables　という関数を見つけた。
早速使ってみると、ちっとも機能しない。
なんと、
mb_convert_encoding は変換したいソース元を第一引数に入れるけど
mb_convert_variables　は　第三引数にいれるという仕様！
そして
mb_convert_encoding　は、
$hoge = mb_convert_encoding みたいに再度代入してやらないといけないけど
mb_convert_variables　代入しなくてもよいという仕様！！
そもそも mb_convert_variables　というネーミングセンスなんなの?
mb_convert_encoding_array　とかにでけんかったの？

>>485
実は確かな技術を持った賢い集団で
自分らの開発は綺麗なソースで行い、リリースの際特製コンバータを通すと
あら不思議、ぐちゃぐちゃスパゲティコード＆意味不明コメント入りオープンソースのできあがり

てな感じか

一貫性のなさはPHPの悪習

名前の付け方も引数の並べ方もこの上なく下手糞

Zendは綺麗、それとDrupal

>>487
俺の場合とは異なるかもしれないけど、
外部に公開するソースは難読化してるわ。コメントも削除してるし。

PHPの難読化ツールでおすすめのある？
安ければ無料じゃなくてもいいけどなるべく無料で

Zend Guardかbcompierくらいか

>>487
オープンソースにする意味ないな

オープンソースです!!って謳うだけでもたらされる効果ってのもありそう。

FREE商法の一種だからな

頭の中がぐちゃぐちゃなのを晒すだけ

オープンソースです！
↓
SEX

こういうわけだな

>>486
そこら辺は俺も学習時に感じたなー

PHPの初期に引数の順番や命名規則を統一していなかったら
もうどうしようもないよね。

PHPは馬鹿が何も考えずに作った言語だからな

どうやらこのスレには天才がたくさんいるらしいから
後世に残る画期的な言語が生まれるのも時間の問題だな

implode
explode
がその例

俺が考えた馬鹿が使う為の言語
間口を広げたら書かれたコードも多種多様となって理解するのに能力が必要に
書く時もその場の乗りで動く状態に出来ちゃう

自然言語を適切に解釈してくれればいい話

ゴミ

それでもこんだけ広まってしまったんだから使い続けようや
ただし別ブランチで「きれいなPHP」というものを作って
そちらに乗り換える方向がいい
というわけで誰か作って

array地獄がなくなった5.4が普及したら本気出すわ

きれいなジャイアンのどこがいいんだ？

5.4でarray地獄って解消したっけ？

配列地獄ってこういうの？
foreach($hogehoge['hage'][55]['fuge'][3]['view'] as $key => $value){
　foreach($value[$this->row] as $key => $value){
　　$splited = split($value['hogehoge']);
　}
}
echo $splited[4];

単にarray()て書き方がうっとうしいってことじゃないかな。
5.4なら[]って書けるし。

設定のためのarray(array(array(array())))みたいなのがなくなるのか

あれあれあれあれあれ〜？

CakePHPも配列多いね。中途半端なオブジェクト指向で気持ち悪いし、非効率。

今CakePHPを使うのは保守くらいだろう
自分出作るのにあえて選ばない

俺はあえて選んでるけど

しばらく使い込んじゃって慣れちゃったから
つい新規の案件もCakeで作っちゃう
乗り換えるとしたらYiiがよさそうだが学習コストが読めなくて躊躇している

フレームワーク使う規模の案件にはPHPは使用しなくなった。

じゃ、なぜこのスレ見に来てるの？
みんなにも「使うなー」って言いに来たのか？

>>518
そういうこと。
仕事ではPHPは単なるテンプレート言語になった。

日本語で尾k

OOPフレームワークでオススメはありますか？
配列地獄は勘弁です。

CakePHPは配列地獄だから、Akelosに移ったという話は見たことあるからそっちがいいんでね？俺はいじった事ないけど。
実際にいじった中では、Pinocoくらいがライトでいいと思ってるんだがまぁ、Symfonyも悪くない選択だと思う。
使えるようになるまでの学習量が半端なく違うけどな。

よほど大規模なければ機能過多だと思うんだ

別に学習しなかったらしなかったで、その分を自前実装するだけなんだけどな

symfonyはダメ。OpenPNEのプラグイン開発でよくわかった。
で、うちはPHPから可能な限りオサラバすることになりました。

よかったね、おめでとう。

俺のとこの会社もPHPから離れつつあるな。
きっかけはVPSの普及やな。

何に移行してるの？Java？

その次がMonoでその次がCobolだな

一回離れたけど、意外とメモリに対してのパフォーマンスが良くて結局PHPに戻ってきた

apache+mod phpはVPS程度の小規模じゃ地味に優秀なんだよな。

浮いたメモリ分をデータベースに割り当てたほうが結果パフォーマンスが上がる

メモリやら鯖のスペックは気にしなくても良いレベルまで来てるからな
処理のパフォーマンスよりも、「いかに早く作れるか？」が重要だろうし、
その点でPHPは優秀だからな

＞メモリやら鯖のスペックは気にしなくても良いレベルまで来てるからな
それはないｗ

サーバーのスペックをどこまで意識するかはアクセスされる数ややる事次第だしな

いかに早く作れようとも、クソコード書いてたら保守でぐだってあいつはダメだって評価になりかねない
自分の仕事としては作りっぱなしのものであっても、最低限の事はできてないと
クソコーダーだってが露見する可能性が常にある状態になるから、流石にアレ

PHPは糞コードを量産しやすい。

糞コーダーが多いだけで、そいつはどんな言語つかっても結果は同じ

とか言ってる奴のコード見るとスパゲティだったりするんだよなw

お前の場合は頭の中がスパゲッティだな

お前の脳はアイスみたいに溶けてるけどな

だからPHPは言語自体がごちゃ混ぜスパゲティだって！

htmlspecialchars
糞関数名の代表

h()

えっちなのはよくないと思います！

hnano()

個人でiphoneアプリ、Windowsアプリをマーケットに売って生き残れ

格安iPhoneEラーニング(学習動画多数あり)
http://tinyurl. com/7wj77om
コワーキングスペースJP
http://tinyurl. com/76vdrny
コワーキング帳
http://tinyurl. com/brzs486
javaやlinuxは手間がかかる　一人でやるには手間がかかりすぎる　手間がかからないで一人で開発できて
人の多いところで直接販売できる仕組みが提供されているメーカ製の言語だけやる　ずばりiphone またはWindow 8 Metro App Store C#
やるならメーカー製の言語 洗練された仕様 脆弱性が少なく 開発ソフトが優れ 課金ライブラリ アップデートライブラリが提供されていて 情報、書籍が多く開発しやすい
奴隷になりたければオープン系をやればいい　時間がかかり 人は多く 仕事の取り合い 足の引っ張り合い 脆弱性が多く 互換性がなく 癖があり 大規模開発中心
詳細設計しかやれない体になって年取ってぽいだ　独立もできない　手間のかかりすぎる仕様だから　

派遣屋 IT経営者はその方が喜ぶ　大規模分割開発では使い捨てしても独立はできまい 代わりはいくらでもいる 嫌なら辞めろ
若い派遣営業は舐めた態度をとってくる ひどいピンハネ

オープン言語、日本独自開発言語・フレームワーク ガラパコ携帯 javascript html5 android java linux python rubyやnode.jsとかやめとけ
メディアに金を払ってステマ宣伝してくるが釣られて手を出しても情報は少なく手間がかかりスパゲッティコードで未完成 デスマに陥る
コンパイルできないからパクられ 　直接売る場所がないから企業に買い叩かれ金にならない　生きれない　ずっと奴隷仕様のままだ

ここから抜け出すにはiPhone一択 またはWindow 8 Metro App Store(未確) C#
Objective-CやC#を覚えるとサーバーサイドからクライアントサイドまでカバーでき人の多い場所でソフトを売る権利を得られる
仕事や趣味でObjective-CやC＃を覚えれば派遣切りされても会社辞めることになってもソフトを売って生きていける　それはセーフティーネットになる
WEBサーバーIIS Win2008ServerVPS SqlServer Oracle MySql 言語はマーケットで売れるメーカー製のみ C#は自分用業務支援ツールとして使える　
例えばPHPでWEBアプリを作っていて管理者画面はC＃(EXEアプリ)で作るとかなり早く作れる（Smartyなんか使うよりもかなり早くだ）
ASP.net(C#)+管理EXEアプリ(C#)+iPhone C#のソースを出さなければWEBアプリの著作権も守れる

C#マーケット　Windows8 Metroアプリ WindowsPhone pad PS Vita Xbox360 iphone(mono使用)
iPhoneマーケット iPhone iPad 予定 iTv iCar i (家電製品)

地方に安い土地を買いコンテナ型の格安高性能オフィスを建て(300万〜500万)
レンタル自習室＆シェアオフィス・コワーキングで収入を得ながらそこでアプリを開発する
http://tinyurl. com/7pb2yaa
http://bit. ly/iLIpJa

これからPHP始める他人に1つ勧めるならCake2.xですかね？
symfony2も人気あるようですが、嫌ってる人も結構いるので
Cakeが一番無難かなと思うんのですが、どうでしょう？

zendやyiiもあるでーよー
まぁ、>>1

Cakeとsympony、ファイル多すぎ。

国内人気、日本語情報量、レンタルサーバーCGIで使いづらい〜とか
全体を見てとにかく無難なのがいいのです。
一端全部触ってみるのはきついです。

>>548
Zendとかに比べて設定ファイルが多いのですか？

設定するファイルは多くないけど、構成ファイルが多い。

作法にそって作る場合はよく考えられてると思うけど、
ちょっと流儀から離れた場合に面倒なことが多いと思う。

フレームワーク一般てそんなもんか。

PHPならではだと思うよ。

これからならYii一択ではないの？

そうでもない

>>552
よう知らんのですが、rubyやpythonのだと、違うの？

Yii普及しないとおもう

新しいこと覚え切れないおっさんには辛いだろうから、下請けに投げたらcakeとか使うんじゃね

なんでおっさんなの？普通、若い子がプログラミングするだろ

若い奴の書いたプログラムなんて、危なっかしくて使えるか

どっちもどっちだな
年齢は全然有益な情報にならない
持ってる知識とかどれくらい興味をもってるかあたりが全て

年齢は関係ないよね。キャリアも関係ない。
fizzbuzzは多少あるっていうか足切りにはなるよね（ならない？）

で、色々あるけど、やっぱりYiiがいーんじゃないか？

Yii選ぶならオレオレの方がマシ。情報量が少ない

新しいけど、fuelphpとかは？

というかPHPはフレームワークに向いていないかと。

俺々は仕事では100%聳え立つ糞

読めない

ただでさえ実行速度が遅くのにフレームワークを使ったらますます遅く

フレームワーク遅くなるのはORMだろ？仕方ないさ。

View+ControllerとModel(ORM)でフレームワーク分かれててほしいとは思うな。

ただでさえメンテ効率悪いのに、フレームワーク使わなかったらますます悪く…

PHP使わなければいいんだけどな。

VSP環境であればうちはPHPは使用しない。
従来のレンタルサーバーであればPHP。

PHPはデータベース周りがクソだから仕方ないさ。
PHPの場合はORMというよりARMだよ。Aは配列。

Cakeは配列指向フレームワークだな。

それはJavaのHibernate(ORM)より
RubyのActiveRecord(ハッシュ？配列？)の方が人気があった流れで
そうなったんだからPHP利用者には受けがいいと思ったんだが、違うのか

＞レンタルサーバーであればPHP。
PHP使う理由ってこれしかないな
軽量とかいうけど、結局効率悪いし

「手軽に使える」ってのは最大の利点だと思うけどな

手軽って何？ hello world するだけならいいけど
Apache Moduleの設定とか含めたら未経験者は大変だと思うぜ

じゃあtomcat？

>>577
未経験者が大変なのはPHPに限った話しじゃないだろw

PHPなら簡単、手軽、軽量ってのが嘘っぱちということ。
一昔前はCライクなのでクラス使うJavaより簡単とか言われてたけど、
多くのフレームワークがクラスのない、オブジェクト指向ではない
古いバージョンのPHPを切り捨てたことでその欺瞞が明らかになった。

プラットフォーム（レンタル鯖）でJavaに対して優位、
政治的な力（世の中の利用者数）でPythonに対して優位だから
使われているのが本音でしょ。

なんだかんだで、PHPで作るのが一番楽だわ
それだけ

>>580
なんだかんだと駄目な理由を付けたいんだな
そんな奴がこのスレに用はないだろ

>>576は足軽

足軽女が来たのか！？

PHPのフレームワークはまともなものが無いと思っていましたが誤解でした。
PHP自体が難ありの言語のためまともなフレームワークができなかったのです。

もうちょっと美味しそうな餌を

餅に見えた

>>585
で、きみの考えた最強の言語は何ですか？

今世紀最強にしてファイナルアンサーはPHPです。

PHPを拡張したPHP++を作りましょう

PHPPP

PHPは完全に作りなおした方がいい。

別の言語使えよw

日本語操作関数が多くて便利なんだよなPHP
pythonはそのあたり結構弱い

その日本語操作関数がこれまた癖だらけ

そうでもない

phpは全部作り変えないとまともにはならないな

日本語処理に特に強いあらゆる文字コードにも対応できる言語を
日本人が作ればいいのだが

そんなの日本でしか使われない
何人が作ってもいいから、マルチ言語に対応してればいいだけ

PHPはダメダメ言語

rubuは？

>>601
うわ、typoしたorz

rubuはうぶです

一旦ageる

symfonyは一体何がしたいわけ？
キャッシュいれても重すぎるよ。

symfony2が最強

ないわー。

このスレの結論として、
PHPはフレームワークを使うとますます重くなるのでフレームワーク不使用を推奨

最近鯖の性能が上がってるからかそこそこ動いちゃうよね
意外とチューニングなしでも運用できてるわ

フレームワークは非推奨になりました。

なんのこっちゃ

PHP自体が重いから、さらに重くするフレームワークを使うなど愚の骨頂

お前は少し体重を軽くしろよ

ＰＨＰ「もう食べられないよ」

重いだけなら状況次第では選択肢にしても良いのでわ

もう食べれないデブー

お前らが作るサイトなんてどうせ人なんて来ないんだから
重くても軽くても一緒だろ

特にセッションがどうのとか言ってたやつ
どうせお前のサイトになんか誰も来ないって

PHPフレームワークは非推奨という結論が出ましたか

お前らのプログラムが非推奨

もう、PHPにはプログラマーなんていらないよ。趣味で覚えたデザイナーだけで充分。

フレームワークが使えないのではなくて、技術者が使えないってのが問題
っていうか技術者と呼べるレベルの奴がほんと少ない
同僚のスキルの低さに涙出そう

PHPだから仕方がないかと。

>>622
具体的にどうひどいの？

>>622
スキルが低いのはお前だけ
そう、お前だけだ

ないわ

PHPerは技術者ではない。

フレームワーク上のプログラムが心配なレベルの人に
好きに作ってなんて言えない…

こんな所で愚痴ってるやつのスキルなど高が知れている

結論でたな。

PHPではフレームワークの使用は非推奨

そもそも、フレームワークフレームワーク叫ぶだけで、実用レベルでOOP使える奴が居ないんだよ。。。

PHPでOOPなんて学べません。実装自体が中途半端です。

OOフレームワークもありません。あるのは配列指向フレームワークです。

phpでオブジェクト指向とか言ってたら笑われますよ・・・

PHPはグローバル関数が1500個以上もある糞言語

OOPとはほど遠い

無能な奴って何でも言語のせいにするよねｗ

>>636
たいしたものも作れない低脳くん乙

煽ることしかできないのかよ…

phpでも工夫次第でなんとかなる。
工夫しなければ論外

PHPで工夫？
ただの悪あがきだろ？
もともとポンコツ言語なんだから何をしようと無駄

そのポンコツ言語に興味持ってるんだろ？

バッドノウハウが身に付きます

cakePHPでcreateした後にsaveしてるんですが
常にアップデートがかかるのみで、インサートがされません。

どういった事が問題として考えられますか？

818 ：nobodyさん [↓] ：2012/08/13(月) 23:03:29.06 ID:???
cakePHP 使ってるんですけど常に行が新規追加されると思いきや更新されてしまいます。
しっかり、 create(); を挟んでいるのですが。

$insert_data = array(
'hoge' => array (
'id' => $login_user_id,
'name' => $post_name,
)
);
$this->hoge->create(); // ←　常に新規追加させる。
$this->hoge->save($insert_data);


819 ：nobodyさん [↓] ：2012/08/13(月) 23:06:25.32 ID:???
>>818
このスレは終了したので別スレで質問してください。


820 ：nobodyさん [mail] ：2012/08/13(月) 23:07:54.81 ID:???
>>818
hogeとか何の疑問も持たずに使ってるお前のような脳弱には無理


821 ：nobodyさん [↓] ：2012/08/13(月) 23:08:02.97 ID:???
>>818
このスレは終了。


【PHP】フレームワーク CakePHP 14ホール目【v2.1】
http://kohada.2ch.net/test/read.cgi/php/1335859124/

<link rel="start" href="file:///C|/Users/じゅん/desk/index.html" />

PHPでJSPのカスタムタグやEL式のような記述ができるテンプレートエンジンと
SAStrutsの2WaySQLのようなことができるライブラリを公開したんだけどどうよ？

テンプレートエンジン
ttp://www.script-factory.com/downloads/prikkeenu.zip

SAStruts風ライブラリ
ttp://www.script-factory.com/downloads/jolokia.zip

ドキュメント整備してないから
サンプルのindex.php見てね。

ちなみに公開はしてないけどCakePHPのレプリカで軽量な奴を作成中。
モデルの検索結果を配列じゃなくてオブジェクトを返すようにしてあります。

名前が嫌だ

>>646
シンプルでいいんじゃない。
EL式とか知らないけど、テンプレートとindex見るだけで何となく動きが見えるし、
そういった方では分かりやすい方だと思う。

SQLは利点がいまいち見えていないので、コメントなし。

あくまで個人的な要望だけど、
テンプレートが短く書ける仕組みとかあったらうれしかった。

> テンプレートが短く書ける仕組み
たとえばどゆこと？

メソッドチェーンとか？
現段階で他のテンプレートライブラリには無い利点は持ってないみたいだし、
個人的に欲しい物を上げようとしたら、短く書ける仕組み。
ただし、具体案はちょっと浮かばないんだけど

$_POSTを渡せばinputとかのname見て勝手に全部入れてくれたら便利じゃない？
まぁ、私が現在進行形で自作してるフレームワークのSmarty連携の機能なんだけど

いわゆるシリアライズ？

>>649
名前はまぁ確かに微妙だとは思ってる・・・

>>650
ご意見どうもです。
これはJSP2.0をPHPで再現しただけなんで
Java使いの人にはなじみやすいかなと。
2Way-SQLはまぁせっかく作ったので公開しただけですｗ

>>652
$user->foo->bar って書式？これそもそもPHPの文法的に許されるんだっけ。
許されないとすれば、そういう書式を許す独自ファイルタイプ作ってパースする…なんてことじゃないよね。

>>653
> $_POSTを(どこに)渡せばinputとかのname見て勝手に全部(どこに)入れてくれたら便利じゃない？
テンプレート側のvalue=""内にデフォルト値として表示してくれるってこと？

>>653
それはテンプレートエンジンの仕事じゃなくて
フレームワークの仕事だと思うよ。

>>646

なるへそ。元Java屋にはいいかもしれんね。
ただ、SmartyやTwigはIDEのサポートが進んでいるからなぁ。
元Java屋でエディタ派ってそう多くは無さそう。

これはどう？国産だけど。

Chimpanzee
http://chimpanzee-php.com/

無名なフレームワーク利用するのと、
オレオレ利用するのって大差ないと思うんだが。

暇だからチンパンジーのマニュアルを読んでるんだけど、説明が分かり難いと思った。
コンセプトは面白そうかもしれない。

チンパンジーって国産だけあって痒いところに手が届くな…
ガラケーサポートとか
あと軽量らしいし

アシアルへのリンク？

お前らサルにはお似合いだな

>>664
猿とチンパンジーは割と遠いんだけど・・・

>>659

version 1.0未満でfixってことはないよね？
いまどうなってるんだろう...

>>659

Twitterも見事に停止してるな。
誰かフォローしてやれよ。

お前ら使ってやらないの？じゃあ俺が使ってやるよ！

>>668

ﾅﾃﾞﾅﾃﾞ ﾅﾃﾞﾅﾃﾞ ﾅﾃﾞﾅﾃﾞ
　ﾅﾃﾞﾅﾃﾞ　　ﾅﾃﾞﾅﾃﾞ
　　　　∧_∧
.∧_∧( ･ω･)∧_∧
( ･ω･)Ｕ))　.(･ω･ )
　⊃)))（ ･ω･)(((⊂
.∧_∧∩))((∩∧_∧
(　　　)　　　　.(　　　)
ﾅﾃﾞﾅﾃﾞ ﾅﾃﾞﾅﾃﾞ ﾅﾃﾞﾅﾃﾞ

http://p11.chip.jp/okanonaoko

チンパンジーって暴力的で愛がないんだって。ボノボは愛があって暴力がないんだって。ボノボの方が良かったんじゃない？

ボノボってあのIBMの

それはレノボ

俺の後ろに立つな

これアシアルが作ってるの？
んじゃ完成度は推して知るべし

>>674

それはゴルゴ

そんなことばっか言ってる子のとこには
しまっちゃうおじさんがあらわれて、どこか知らないところにつれていかれて
どんどんしまわれちゃうんだ…(´；ω；｀)

オープンソースなのに情報が少ないからクローズソース
動的だから変更のたびに　チェックと確認が必要　
ローカル環境→開発サーバー→ステージング→本番　これを毎回やる
クラス・関数一覧のドキュメント一覧とか大量に必要にしかも仕様変更
のたびに変更が必要　大規模だと必ずこんがらがる
バージョンアップのたびに別物に生まれ変わり　また学習しないといけない
新しいＦＷがしょっちゅう出て　それがデフォルトスタンダードのような
宣伝やめてくれないか

実行しないとバグがわからなすぎる動的言語は過去のライブラリを使うの
ためらう　結局過去の資産を生かせない　関数の名前の変更のたびに
ソース検索が必要で手間がかかる　これが静的言語だったらエラーはくから　
確認チェックの手間がローカル環境内で収まることが多い　動的は作れば
作るほど負債化し　作っては捨てたほうが早いの繰り返し　どうしようもない
動的言語をはてぶを始め技法やCodeZine　アシアルの宣伝は本当に
罪深い　

結局これは短期記録力がある人間の驕りなんだよね。（東大とかアシアルとか）
彼らは自分たちの記憶能力を生かしたいがために
ガラクタ言語をチョイスしてそれをスタンダードのような流れにしたいと思っている
このガラクタ言語を使うことで短記録のある自分たちが有利であることを知っていて　
他を蹴落としたいと潜在的に思っている。ハテブやらで流れを作ろうとたくらんでいる
静的言語を使えば（主にＣ＃）こんな苦労なんて全然ないのに　
それでは自分たちが存在意義が問われるからあえて使わないようにしている
いい加減こんなガラクタ言語やっていても無限に苦労することなる
　

動的はやめとけ無限に苦労することになる　書けば書くほど大変になる
記録力のあるやつだけやつしか現場に残らない　記録に止めないといけないこと
多すぎるからだ　VisualStudioやC#だったらバグ、リファレンスエラーを教えてくれる　記憶力よりプログラムを書く想像力方が大事になってくる
動的は流れを把握するのが時間がかかるから、ＭＶＣに合わせていたが　ソフトがバグを教えてくれるならも っと効率的な書きをして　他人はVisualStudioやC#の機能から理解にいたることできる
つまらない他人のＭＶＣに合わせないでも効率的な面白い書き方でやっていけるはず　ドカタから芸術家に脱却できる

>>677
それはぼのぼの

日本語でおk

何処縦に読めばいいかわからない
もしかして斜め？高度だな

アサヒビールが販売してる焼酎がお気に入りだ。
この商品名は良い香りという意味で付けたらしい。

こんな中身のない長文を思いつきで書ける人ってすごいと思うの

あー、あの第64代横綱ね

>>685

それはかのか

>>687

それは曙

チンパンジーってZFの影響を受けてるとみた。
ってか、焼き直しっぽい感じがした。

国産のFWってのは魅力だけど、これから新しい物作るんなら
少なくとも英語には対応したサイトで間口を広げないと
コミュニティの広がりに関してはなかなか難しいよな気がする。
なんだかんだ言っても英語を使うと新しいつながりが半端ないし、
やっぱりインターネットって米軍のお下がりだしな。

少なくとも新しいPHPFWはもうちょっと無理がある気がする
いっぱいある古参系のを使い続けるか、Yiiだとかそのあたりの
比較的あたらしめの奴を覚えて乗り換えるかのどっちかじゃね

俺々フレームワークに毛が生えたようなだけの小規模系FWだと、
需要が限りなく0なので覚える時間が無駄になる可能性が高すぎるんだもの…

小規模すぎると、覚えた途端に開発終了もあり得るしな

で、別人たちの改造版に分裂

おっと、CodeIgniterの悪口はそこまでだ
本家もまったり続いてるけどな

もうどのFWも単なる言語拡張積み上げてるだけな気がしてきた
正直MVCすら要らん、MVCの思想は凄いけど形だけあっても無意味なような。

symfonyの1だけはちゃんと思想が脈打ってて感動した。2は何であんなことになったのだろう

symfonyのアレを思想というのか。
それほど崇高な印象はないなぁ。

開発ブログを読む限り、BEAR.Sundayは良いかも知れない。
完成すれば、既存のFWの対抗軸になりうる予感。

laravelがよさそう
fuelphp流行ってるのは日本だけだし
yiiかlaravelに乗り換えたい

fuelも別に流行ってないけどな

最近はCakeの情報が少し充実してきたのかな？

cake2の情報が少ないし
見つかるプラグインは1用ばっか

PHPの開発自体減ってるのかな？記事関係はRubyばっかりだ。
だが、新サイトで見るのは大体PHPだけど

特に最近は、自分から発信する開発者がRubyのほうが多い感じを受ける。
言語としての優位性の比較はともかく、その点ではRubyはいいかもね。

>>703
情報発信者が多いのは結構だけどなぁ・・・
rubyってバッドノウハウ多くね？

っと、PHPスレで他言語disっちゃいかんな。ごめんよ

PHPをdisれ

バッドノウハウの多さを競うならPHPだって負けてないぞ

yiiとCodeIguniter迷いすぎる

CodeIguniterでいんじゃね？

スペルが違うんじゃね？

CodeInuguier

Wii

ASP.net 2人かかる仕事は
PHP 3人
RUBY 4人
JAVA 5人

機能を追加時の増員の必要割合

ASP.net 開発者 小 デバッカー　小
PHP 開発者 中 デバッカー　大
RUBY 開発者 中 デバッカー　大
JAVA 開発者 大 デバッカー　中

動的言語やLAMPはバットノウハウなのは確か
まねするとコストばかりかかり　雪達だるま式にデバッグやらコード修正が増えていき
苦労することになる
大手しか開発できないような仕組まれてる　ガラパコス利権

デバッカー
バットノウハウ
雪達だるま

コード修正が必要なのはお前だ

ガラパコスについては大目に見てやろう

アプリ起業iPhoneC#まとめ Ver 1.5
ｈｔｔｐ:／／tinyurl.　com/9w97424

ブラクラ

もしブラクラだったら警察に通報して逮捕になるから別にいい

綺麗なサンプルphpコードを一つ見本にして全員で真似するのが
一番開発もメンテも楽な（メタ的な）フレームワーク

その作業工程は、延焼していく炎を思わせるため、flameworkと呼ばれる[3][4]。

こんなのあるみたいよ。

---------------------------------------------------------
CodeIgniter Talk #01 2013/06/22 (土) 14:30 - 17:30 @ 渋谷
http://codeigniter-talk.doorkeeper.jp/events/4062

714と715、面白いな。

>>720
flameworkって普通にある単語なんだが

>>723
その普通のflameworkの意味をちょっと説明してみてよ

flamework (三人称単数 現在形 flameworks, 現在分詞 flameworking, 過去形および過去分詞形 flameworked)

To lampwork.

んで、
lampwork (uncountable)

(glassblowing) A method for working with blown glass that does not require a furnace.
(glassblowing) Glass pieces made by this method.
(glassblowing) The activity of producing glass pieces using this method.

普通にスレチ(´ω`)

普通に使われてることの証明になってない

>>727
辞書をひくことすらできないお馬鹿さん、乙

ウィクショナリーが辞書だと思い込んでるゴミ乙

PHPのフレームワークって、よく名前が出るものだけでも
いくつもあるから、いまいち何使っていいかわからん。
適当に選んで、使って試して、だんだんわかっていくしかないのか・・・

しばらく前にZendでやってみたものの、利点も欠点もなにも、
これといった印象なかったし、違いのわかる男にはなれそうにないぜｗ

>>730
俺もそう。何使っていいかわからん。

ただ、規約に縛られるフレームワークは嫌。
規約を知らないと摩訶不思議な動作をするように見えるから。

規約なんて、開発完了しちゃえば直ぐ忘れてしまうもの。
規約を忘れた１年後の自分は、そのコードをメンテできそうもない。

規約に縛られないフレームワークでは
自分で規約を作るだけ。

結局、規約に従ってプログラムするのは当たり前。


でなければ、行き当たりばったりの開発をするかだ。
こっちはもっと最悪。
何も決まっていない、似ている処理なのに
規約がないから、微妙に違ったコードになってる。
開発をするたびに、コードを読まないとわからない。
忘れる以前に覚えられない。

>>730
> しばらく前にZendでやってみたものの、利点も欠点もなにも、
> これといった印象なかったし

アーキテクチャってものを知っているか？
設計のことだが、どちらかと言えばコードレベルの設計の話。
アーキテクチャを知らなければ、フレームワークを見ても
単にいろんなライブラリがあるようにしか見えない。

アーキテクチャを知っていれば全体がひとつの塊として
考えられて作られていると理解できるようになる。
どう作っていいかがわかってくる。

経験を積めば、コードを見るだけで
あぁ。こうしろってことねと意図がわかる。
そうなると、ここにこの機能があるはずと推測できるようになる。

つまり君はまだアーキテクチャを知らんのだ。動けばそこで終わりという開発をしてるだろう？
単にフレームワークを使うのではなく、フレームワークをどのように使ったら
効率がいいかを考えながら作れば、アーキテクチャを理解できるようになる。

コードレベルって書くとむしろ1〜数行レベルの話しに聞こえちゃう

733は随分上から目線だけど、そんなヤツに限ってデキないんだよな。
これは俺の回りの現場の人間を見ての経験則だけどね。


アーキテクチャって言葉を知りはじめて、使ってみたいのかな。

>>732
俺の言う規約というのは、例えば、CakePHPの場合、

DBのテーブルに created_at というフィールドがあれば自動的に
値が書き込まれる・・・

ということ。

これらは、自分が書いたコードを追うだけでは挙動を理解でき
ず、CakePHPを知っていないとダメなんだよね。

規約に縛られるフレームワークは、規約により自動化されることが
多いのでコードを書く量が減り開発が速いけど、規約を忘れたときの
メンテが大変、という感じがします。

慣れてしまえば心配無用なのかな？

規約が紳士協定レベルじゃなくて制限として存在してくれれば
困ることはないんだけどな

>>736
created_at は ROR
CakePHPは created

>>736
もしそういう規約がなかったらで考えよう。

日付が格納されるフィールド名はバラバラ
ある所はcreated_atだったり、ある所はcreatedだったり
ある所はcreate_dateだったり。

そうならないときに「コーディング規約で決める」というふうにやっぱり規約が出てくる。
規約を忘れたら、バラバラのフィールド名になる。
規約を思い返すのならCakePHPの規約を思い出せるだろう。

フィールド名がバラバラなだけではなく、あるところは
日時なのにあるところは日付だけだったり、コードを読めばわかるだろうが、
フィールド名を見ただけでわからず、該当フィールドに格納しているコードを
一つ一つ読まないと確証が得られない。

規約を忘れたらというが、規約を忘れるような人は手作業で書いたコードも忘れる。
コードを読み返す時間があるのなら、CakePHPの規約を読んだほうが早い。

忘れた時にメンテが大変なのはどっち？ コードを読むのが苦痛じゃないから
実際に時間がかかってるはコードを読む方なのに楽だと勘違いしているだけ。

コピペしたほうが早い。
forループはfor文を忘れた時にメンテナンスが大変。


結局はこう言ってるのと同じ。

はい？

>>733
ダラダラ書いてるが1〜数行レベルで済むレベルの話

>>742
じゃあ一〜数行でかけよｗ

規約違反はエラーになるPHP用文法チェッカがほしい
って探せばありそうだな

つ codesniffer

>>745
こんなのがあるんだ
これってCake用っぽいけど、オレフレームワークでも使えるかな
ちょっと試すか

全然Cake専用とかじゃなかった。 これ便利そう！ありがとう！

え？なに？ なんか知らないけど、どういたしまして！

とりあえず初心者は何やれば良いの？

初心者なら、一度でいいからフレームワークを使わずに作る
で、「あれができたらいいな」とか「これを簡略化したい」などを
まとめ、それから、それらを実現できそうなフレームワークを探す

PHP初心者じゃなくてFW初心者ってことなら
とりあえず情報量の多いCakePHPからやるのが無難だろうな。
まわりに詳しい人がいたらその人が使ってるFWでも良いと思う。

地力の無い奴がフレームワークに手を出すと大抵コードが腐る。

まず大半の初級者は Model = DBテーブル と刷り込まれて、
正しいMVC分けが出来なくなり、Controllerが糞みたいに肥大化する。

普通に考えれば、別途ライブラリ(真の意味でモデルに該当するモノ)を構築すれば良いのだが、
それが出来ない。全部コントローラに記述しちゃう。

また大半のフレームワークではメソッドやコントローラアクションに関する粒度が規定されていない為、
1メソッドが糞みたいに長かったり、1コントローラに全ロジックが書かれたりする。

素人は一度は自作FWを作る経験をすべき。

一度でいいけどな

モデルを理解したうえであらためてCake使うと
「ファーーーｗｗｗｗ よう考えられとんねーー」
と思うこと請け合い

え？
cakeがよく考えられてることとはネタですか

笑ってるから、馬鹿にしてるんでしょ
実際は笑えないことが多いんだけど

cake激安レンタル鯖に入れたら重すぎて使う気起きなかったよｗ

cakeなんか使うからｗ

で、何がお勧めなの？
出来ればそれを選ぶメリットも一緒に

ケースバイケースとしか言いようが無い。
FWのせいで効率が落ちる＆保守性が落ちるのは本末転倒なので好きなの選べばいい。
Cakeは開発グダグダだし、独自方言大杉で他FWに移行し辛いし、一緒に心中する覚悟が必要かな


最近だとIDEとの親和性も大事だね

fuelPHPとか最近よく聞くけどどうなんだろう

FuelPHP
CodeIgniter のライセンスの問題で話題になっただけで、
他と比べて特別何か優れてるわけでは無い

＞IDEとの親和性も大事だね

俺もそう思う。

もうこれほとんど生PHPだろ・・・ 超便利だけど・・・

というようなフレームワークってある？

文句は出るがお勧めはないってのがさすがphp

>>763
生PHP＝独自設定ファイルが不要という意味ならば、
Zendとかじゃね？フレームワークとしては微妙だけど、ライブラリとしてはまぁまぁ便利

>>764
どのFWも一長一短な上、無駄に種類が多いからね･･････

slimオススメ

>>759 >>762
IDEと親和性が高いフレームワークでオススメってある？

phpStorm使い始めたんだけど、コード補完が効かないと耐えられない体になってしまったよ

俺も知りたい。
VisualStudioでアプリ作ってると、コード補完が効かないのは耐えられない。

CakePHPはプラグインあるよ
他もあると思うけど使わないから知らない

NetBeansにCakeのプラグインあって入れたけど
結局素のPHPの部分しか、解釈してくれないようだ
コンポーネントの関数とかまで見つけてサジェストしてくれたら、最高なんだが

ウェブ系って静的解析が難しい言語ばかりだからね。

実際に実行される直前になるまで
変数に入っている型がわからないなら
補完できなくて当然なわけで。

>>771
＞実際に実行される直前になるまで
＞変数に入っている型がわからないなら
＞補完できなくて当然なわけで。

そう思っていた時期が俺にもありました。
が、最近のIDEはコードとコードコメントから中身を推察して、凄い精度で補完してくれるんだよ。

ただし、マジックメソッドを多用してたり、PHPコードでは無く文字列や設定ファイルを多用してると、流石に無理でCakeは相性が悪い。

コメントから中身を推察ってすげえな。本当にできるの？

// たぶん動くと思う

>>773
出来るどころか、その逆、コードを解析してコメント入力の補完までしてくれるよ。
以下のメソッドがあるとする。

function getHoge($a = 1) {
return new Hoge($a)
}

1. コードから型を推察する

$a = getHoge(); // $a はHogeインスタンスとして認識される
　$a->xxxxx; // $a-> と入力すると xxxxx が補完される

2. コードからコメントを補完

/** と打つと、以下のコメントひな形を自動入力してくれる。
　この @return にメソッドが返すべき型を指定すると、IDEはそれを認識する。
　(@returnが無くても上記のコード推察機能は動く)

/**
* @param int $a
* @return Hoge
*/
function getHoge($a = 1)

言語の欠陥をコメントで補ってる系

>>776
アノテーションってご存じですか？

間違いなく言語の欠陥

型付けが無いメリットとデメリットのうち、デメリットだけをアノテーションで解決出来るとかどこの神言語だよ

変数の型をコメントで指定するぐらいなら、
普通に変数に型を書いたほうが
見やすいと思うよｗ

Bare Sunday なんかはフレームワークそのものを
アノテーションで駆動させてますよ

あ、 Bear Sunday の間違いだった

DRYの原則からすると、


/**
* @param int $a
* @return Hoge
*/
function getHoge($a = 1)

$aを二回書くのは無駄でしか無いね。
もっと言えば@paramも無駄だし@returnも無駄。

こんな感じでコメントを書く場所が厳密に決まっていて
同じ事を二回書かなくて済む言語出来ないかねぇ。

// 関数と戻り値のコメントを書く。
function Hoge getHoge(
　int value,　// ここに引数のコメントを書く
　string str,　// ここに引数のコメントを書く
) {
・・・
}

valueが@paramなのは自明だし型も自明

アノテーションがどういう物か判ってて書いてるんだろか
DRYが何か判ってて書いてるんだろか

読んでるこっちが恥ずかしくなるわ

そう言葉を残すだけで
反論はできないのであった

完でいい？

>>780
変数に対する型指定アノテーションも存在するよ
厳密に型指定したいならPHP以外を使えば良いんじゃね？

>>783
コメントは別に「型」を記載する為だけのものじゃないからね。
あと、君が上げてるサンプルは長文になった時、確実に可読性が確実に落ちると思うんだがｗ

＞コメントを書く場所が厳密に決まっていて
うん。それがphpdocだ。
C〜C#、Javaあたりのソース読んでみ同じような事してるよ

> あと、君が上げてるサンプルは長文になった時、確実に可読性が確実に落ちると思うんだがｗ

長文になる時は別の書き方を用意すればいいだけの話。

// 関数と戻り値のコメントを書く。
// [*1] : 長いコメント
// [*2] : 長いコメント
function Hoge getHoge(
　int value,　// 短いコメント [*1]
　string str,　// 短いコメント [*2]
) {
・・・
}

重要なのは、コードを変更した時、同じ事を二度やらなければいけないということ。
コードとドキュメントの整合性が取れなくなるのは、これが理由。

>>786
> 変数に対する型指定アノテーションも存在するよ

いや、だから型指定アノテーション＝型指定でしょ？

>>787
君が言いたい事はわかるが、とうの昔に多言語で実装されている。

・MS系(VB/C/C#)のドキュメントコメント
・Java系のjavadoc
・ECMAScript(JS/AS/etc)のコメント

phpdocはそれに倣っただけだ。
あとアノテーションについて学べ。まずはそこからだ。

＞重要なのは、コードを変更した時、同じ事を二度やらなければいけないということ。
IDEが自動で変えてくれる。

＞コードとドキュメントの整合性が取れなくなるのは、これが理由。
整合性がとれなくなるのは、開発者が無知だからであって、言語のせいでは無いよ。

＞長文になる時は別の書き方を用意すればいいだけの話。
長いコメントと短いコメントの記載場所が2箇所に別れちゃうんだｗ
で、長いコメント書く場合の改行やパラメータの区切りはどうすんの？ @param とか明示的な文法が必要じゃね？

>>789
ドキュメントコメントってこれ？
http://msdn.microsoft.com/ja-jp/library/8cw818w8(v=vs.90).aspx

俺の方法では不要なparamが使われている。
Int1という名前が二回出てきている。

javadoc もECMAScriptのコメントも同じ。

> IDEが自動で変えてくれる。
IDE使わないときはどうすんの？

> 長いコメントと短いコメントの記載場所が2箇所に別れちゃうんだｗ
> で、長いコメント書く場合の改行やパラメータの区切りはどうすんの？ @param とか明示的な文法が必要じゃね？

短い時に短くかけるのがメリット。

たいていは短いのだから
多くのものを短く出来るのはいいことだ。

>>788
＞型指定アノテーション＝型指定
違う。「言語」としての型指定では無い、所詮はただのコメント文。
コメントにルールと意味を含める事で、言語を拡張するイメージだよ。

最近ならAndroid系のソースコード読めばアノテーションの存在意義が理解しやすいよ。
ピュアなJavaコードなんだけど、Android独自文法を実現している。

>>791
＞たいていは短いのだから、多くのものを短く出来るのはいいことだ。
答えになっていない。
長いコメントの区切りはどうするの？
パラメータの順番が変わったらどうするの？
お前、まともにとリファレンスコメント書いた事ないだろ。

＞IDE使わないときはどうすんの？
IDEの為にアノテーション使おうって話なんだが？

僕の考えた最強のコメントルールってやつだな･･････ｗ
独自フレームワークより害悪だわ

　　　　　　 /　　　/ヽi,',. ',　ヽ.　 　 　 ヽ　ヽ　 _
　 　 　 　 ,' 　 i　,' '"´ ヽ.l＼ ',,ヽ　　　　'､ ､.'､!_ゝ-r- ､
　　　 ,. '"i .i　 l .,'　　 ,./ヾヽ,ヽヾヽ　.l､. N　ヽi i., ' ., ,.' ﾍ
　　　,'-_.,' .l　/!.l..-‐'´　　 　 ｀ヾ''''ヽ l.', l }｀'‐l l' .,.,'i´　　i
　　　',__/,　! ,'´'l _,,,,_ ､　　　　r-==.-'､.l,' .'z ..', V/ヾ.､　ﾉ
　　　 ゝ,'l　N ,ｨr'´￣｀　　　　　　　 ｀r'っ　'i _. ｨ'ヽ--｀'
　　　'´　.! i'l !r'/i/i　　丶 　 　 '´'´'　｀i !　 ´,ヾl　 !
　　　　　 ',!.l.ll.!　　　 r=＝ﾆ'‐ヽ.　　　 l ! 　 ,' ,.,i　 !
　　　　　　 i. ',l.　　　 !:::;: -‐‐-:;i　　　 l.!　, ','.ｲ.l　 !　　やっと【PHPフレームワーク総合スレ15】
　　　 　 　 !　','､　 　 l.{　　　　 ,l　　　,'i.,.'.'´　.l. !　.l　　が盛り上がってまいりました！
　　　　　　i 　 !.l＼.　 ヾ=== ' '　　 ノイ´　　 .l. l　 i
　　　　　　!　 .! !　 ｀' .､ 　 　 　 ,. ｰ',.. 'i　　　 .l. l　 l
　　　　 　 !　 .! !　　　','､' ー. '"r;''"‐'´i　　　　.!. !　.!
　 　 　 　 !　 .! l　　 　 !ヽ'i´i-´' 　 　 .|　 　 　 !. i　 !
.　　 　 　 !　 .i .!　　 　 !　 ! |　　 　 　 '､　　 　 !. i　 i
　　　　　 i　 .i .i　　,.- '　 く.r'_,,.'''''　　　 ヽ、　　',. i　 i
　　 　 　 !　 i_,i.ｨ'"　　　　i i　　　　　　　　 ｀'i;--' ､　.i
　　　　　i , '´ 〃＿＿　 .,'.,'　　＿_　　　　　,','　 　 ヽ i

>>793
> 長いコメントの区切りはどうするの？
[*1]って書いてるじゃんｗ

> パラメータの順番が変わったらどうするの？
変わってなにか困るの？

>>796
[*1]とか[*2]は無いｗｗ
@param $var の方が良いわｗ

＞＞パラメータの順番が変わったらどうするの？
＞変わってなにか困るの？
>> 787 で
＞重要なのは、コードを変更した時、同じ事を二度やらなければいけないということ。

[*1] だと数字を全て書き換える必要があるよね？
(書き換えないのであれば、相当可読性落ちる)
何より長文と短文を紐付ける [*1] が人的管理とかねぇわｗ

試しにそのコメント処理パーサ実装してみ？

引数と戻り値の言及ばかりで、
@see / @author / @todo / @throw あたりを考慮してない時点で察してやれよ･･････
コメント文をまともに書いた事も、ドキュメントを作成した事も無いんだよ･･････

>>783 で
＞ $aを二回書くのは無駄でしか無いね。
と言っているのに >>787 では
$aの代わりに [*1] を二回書いているというねｗ

> [*1] だと数字を全て書き換える必要があるよね？
> (書き換えないのであれば、相当可読性落ちる)

書き換えなきゃいいじゃんｗ
可読性？ 落ちない落ちないｗ

> 試しにそのコメント処理パーサ実装してみ？
なんか難しいの？ｗ

http://kojika17.com/2013/01/starting-markdown.html
> I get 10 times more traffic from [Google] [1] than from
> [Yahoo] [2] or [MSN] [3].
>
> [1]: http://google.com/ "Google"
> [2]: http://search.yahoo.com/ "Yahoo Search"
> [3]: http://search.msn.com/ "MSN Search"

>>799
> $aの代わりに [*1] を二回書いているというねｗ
長文だからだろ？

短文（大半）は一回でいい。

PHPerが総じてキモイのがよく分かった

PHPerだけど、こんな奴と一緒にしないで欲しい

>>800 がピーピー騒いでるだけだろｗ
Markdown記法持ち出してるが･･････で？

IDEとの親和性が抜群に上がるので皆phpdoc書こうぜ！って話なのだから、
当然IDE用の何かがあるんだよな？ｗ

　　　　　　　　　　　　　（　　ヽ　　　　　　――――　　○　　――――
　　　　 ,　⌒ヽ　　　　(　　　　　）　　　　　　　　　　／/ |　＼
　　　 （　　　　'　　　（　　　　　　　ヽ⌒ヽ 、　　 ／　/　|　 　 ＼
　　　　ゝ　　　　｀ヽ(　　　　　　　　　　　 　 ）.. 　 　 　 　|　(⌒ 、
　　　( 　　　　　　　　　　 ⌒　　　　　　　　　ヽ　　　　　 （　 　 　ヽ

　　　　　　　 　　 ∧__∧　 　　【PHPフレームワーク総合スレ15】が
　　　　　　　　　（ ´･ω･） 　　盛り上がってまいりました
　　　　　　　　　 （　 つ(＼
　　　　　　 (＼_ノ(___)⌒　⌒ヽ_
　　　　　　　）　＿＿＿＿　　・_つ　
　　　　　　（／　　　　　　（／　　　　
　　　　｡　ﾟ　　　　　　　　　　　　　　
　　　｡　ﾟ　　　　　　　　　　　　　　　
　〜〜〜〜　　〜〜　　〜〜　　〜〜　　〜〜　　〜〜　　〜〜　　〜　〜
〜〜　　〜〜　　〜〜　　〜〜　　〜〜　　〜〜　　〜〜　　〜〜　　〜
　　　〜〜　　〜〜　　〜　　　〜〜　　〜〜　　〜　　〜〜　　〜〜　　〜

PHPerでも無いだろｗ
俺の考えた最強の言語厨ｗ

まともにコード書いた事が無いんだろうよ

まーた、中身の無い反論（？）をｗ

IDEを使って無い情弱が混ざっているという事だけは確かだなｗ

PHPerは補完に頼りっきりの行き当たりばったりのコードを書くからそんなことになる

そんなことって？

×PHPerは補完に頼りっきり
○PHPerは補完に頼れなかったのが、頼れるようになってきた

僕は　ほかんなんてなくても　ゆうしゅうです　てか？涙拭けよｗ

補完されなくてもできるが、機械的にできることに注力するのはただの無駄
無駄なことに凝ってるのは、優秀ではないよ
道具を使いこなせなければ猿ですらない

道具に使われてる典型的な例だな
こういう奴に限ってIDE無いとプログラム書けなかったりする
環境に左右される様なプログラミングしてる奴が優秀とかよく言えたもんだ

>>812
GJ

>>813
うわー、懐古厨？老害？

何か勘違いしてるようだけど、PHPerはIDEが無くても書ける。
（今までまともなIDEが存在し無かった)
故にコード品質を保つのに、人手が･･･つまり「無駄」な時間が割かれていた。

IDEを使えば、綺麗に短時間で効率良く書ける。
コメント、リファクタリング、テストコード、バージョン管理、コードリーディング、全て補佐してくれる。

「使わない」理由があるか？
君が「道具」すら使いこなせず、選択肢を狭めてるだけじゃね？

>>814

>何か勘違いしてるようだけど、PHPerはIDEが無くても書ける。
>（今までまともなIDEが存在し無かった)
>故にコード品質を保つのに、人手が･･･つまり「無駄」な時間が割かれていた。

自覚してんじゃん
XPHPerはIDEが無くても書ける
○IDEが無いと品質を保ったコードが書けない

>IDEを使えば、綺麗に短時間で効率良く書ける。
>コメント、リファクタリング、テストコード、バージョン管理、コードリーディング、全て補佐してくれる。

当たり前だろ
IDEって何の略か知ってんのか？

>「使わない」理由があるか？
>君が「道具」すら使いこなせず、選択肢を狭めてるだけじゃね？

使いこなすとか使いこなせないとかじゃなくて
「当たり前」の事をドヤ顔で誇らしげに言ってるPHPerが気持ち悪い

大体PHPでアノテーション使えるようになったのはいつからだよ
PHPerはほんとにPHPしか知らないんだな

>>815
お前は他言語はおろかPHPもIDEも使って無いっぽいねｗ
てか、話の前後を読めないの･･･アスペ？

＞大体PHPでアノテーション使えるようになったのはいつからだよ
PHPという名前になる前からアノテーション自体は定義出来たよ。
アノテーションの意味解ってる？ｗ

＞当たり前だろ
＞IDEって何の略か知ってんのか？
＞使いこなすとか使いこなせないとかじゃなくて
＞「当たり前」の事をドヤ顔で誇らしげに言ってるPHPerが気持ち悪い

「当たり前」であるIDEを使って無い奴がいる、
「当たり前」であるIDEを環境依存と難癖つけてる >>813 がいる

そして残念ながら、PHPという言語はIDEが「当たり前」に浸透してないんだよ。
アノテーション定義は出来ても解釈出来るIDEが無かったんだよ。


それが、昨今急激に進化して他言語IDEと肩を並べられるようになった。
故にフレームワークとIDEの親和性が重要になってきた。

昔のPHP事情で煽れても、情弱としか言いようが無い。

そいつ書籍スレや質問スレを荒らしてるキチガイだろ
Javaで挫折してPHP入門しようとたところ、スレで無知を馬鹿にされた逆恨みでタタリ神になってから
PHPを貶めるため年中スレを監視するお仕事をしてる

アノテーションをIDEで利用する注釈程度にしか理解してないのはよく判った
言語仕様の話してんのになにが「PHPという名前になる前からアノテーション自体は定義出来たよ」だよ
本物のアホだな

それとな

>てか、話の前後を読めないの･･･アスペ？

とか

>そいつ書籍スレや質問スレを荒らしてるキチガイだろ

とかさ
別に2chだからとかって言い訳したいんだったらそれでいいけどよ
そういう煽りしか出来ないからお前らゆとりは相手にされてないんだよ
技術的な話するなら技術的な事で煽れよ

だいたい「そいつ」って何だ
IDもないスレで人物を特定して何の意味があるんだ
PHPと同じで存在する価値がないゴミだな

なんかこの板的に、今までにない勢いでスレが伸びてるな

>>818
＞言語仕様の話してんのになにが「PHPという名前になる前からアノテーション自体は定義出来たよ」だよ

phpdoc等のアノテーションは言語仕様としては「コメント」以外の意味を持たない。
(コメントを取得するリフレクションクラスは存在し、それを使ってアノテーションを解析するコードを書く事は可能)

で、「言語仕様」としてPHPがアノテーションを定義出来るバージョンていくつからだい？
定義方法と併せて、無知な私に教えてください

どうでもいいけど、C#から生まれた
アノテーション（正式には属性）が
ここまで普及するとは思わなかった。

古くはVBにこの機能があったんだけどな。
http://www.excellenceweb.net/vba/class/default_member.html
http://www.excellenceweb.net/vba/class/img/default_member/010.jpg
> Public Property Get Value() As Long
> Attribute Value.VB_UserMemId = 0　　　　← これ
> 　Value = MyValue
> End Property

>>822
え、アノテーションて Java からじゃなかったのか
C# は殆ど触ったこと無いんだが、意外

>>821
提案はされてるけどサポートはまだしてないんじゃないっけ？
https://wiki.php.net/rfc/annotations-in-docblock
ただフレームワークレベルではsymfony2とかサポートしてるし
doctrineやphpunitでもphpdocでも使ってるからphp5以降から一般化してる気がする
リフレクションクラスも5以降じゃないっけ？

>>822,833
俺もJavaからだと思ってた

あぁなるほど
>>815は公式にアノテーションがサポートされてないのにいつから使える様になったのか？って言ってるのか
それを>>816が定義ができるとか言ってるから話がおかしくなってるんだな
それに対しての>>818のレスで意味が通じたわ

公式にサポートしてないからアノテーションの記法をしてもただのコメントなのに
定義が出来るとか言うのがおかしいって事であってる？

とりあえず話の流れ的には勉強になって良いんだけど
スレ違いだから他でやって欲しい気もするかな

>>825
＞公式にサポートしてないからアノテーションの記法をしてもただのコメントなのに
＞定義が出来るとか言うのがおかしいって事であってる？

いや、アノテーションとは本来言語に影響を与えない、コメント(注釈)に意味を持たせる事にあるんだよ。
それが「公式」か「非公式」は関係無いんだよ。

phpdoc の @author @param 等も立派なアノテーション
(IDEや、phpDocumentor/Doxygen等のドキュメント生成ソフトが対応している)

なのでPHP3だろうが4だろうが、定義は可能だし、上で上げたソフトで処理も可能だ。

今日もまた不毛な議論が続いてるなｗ

>>826
アノテーションって言語の拡張的な意味合いがあると思ってたんだけど違うの？
少なくともJavaは言語の仕様としてアノテーションは含まれてると思うんだけど
http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%8E%E3%83%86%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3

ただ書いただけで定義が可能って言い切るのは乱暴な気がするなぁ

不毛な議論は飽きたから無毛女子の議論をしようぜ

ていうか、ここフレームワークのスレだよね

じゃあネタ振りしてみる

最近、マイクロフレームワークが気になってるんだけど
スレ住人的にはマイクロフレームワークって使ってる？

俺はSlimとSilexを勉強してたりするんだけどシンプルでいいよね

使いどころは？初心者ならともかく、どこにつかうんだろ

>828
＞アノテーションとは、あるデータに対して関連する情報（メタデータ）を注釈として付与すること。
＞XML等の記述形式を用いてメタデータをタグ付けする場合が多い。付与したメタデータやタグを指してアノテーションという場合もある。

は読んだ？

その上で phpdoc がアノテーションでは無い、と思うならアノテーションでは無いのだろう。お前の中では。

なぜこんなに必死なのか

>>832
むしろフルスタックのフレームワークの方が初心者向けな気がするが
シンプルな方が縛りが無くて自由な分PHPに慣れてないと使えないと思う

phpdocはアノテーション使えるって必死な奴以外は、phpって言語でアノテーション使えるかって聞いてるだけに見えるんだが。
アプリレベルの話と言語レベルの話とごっちゃにしてるから一生解り会えないと思う。いい加減スレチだから他でやれや

アノテーション云々は置いておいて、
IDEと親和性の高いフレームワークの話しようぜ

具体的に教えて欲しい。
例えば、

　NetBeansでCodeIgniterの補完をさせたいときのオススメの方法。
　EclipseでCakePHPの補完をさせたいときのオススメの方法。

コメントに@propertyとか書くだけではダメなんだけど、”高い精度”で
補完させる方法を教えて。

>>838
http://kohada.2ch.net/test/read.cgi/php/1375636484/

フレームワークの話題だからここでいいだろ

>>838
まず Netbeans と Eclipse(PDT) は補完精度が非常に低い

　・全てのメソッドに @return で型を指定する
　・全ての変数/プロパティに @var で型を指定する

この二つを満たさないとまともに機能しない
マジックメソッド(__get や __call)を使用しているFWとは非常に相性が悪い。

最近話題の phpStorm を一度試してみ？
PHPコードを解析して"桁違いの精度"で補完してくれる
コメントを書く必要が無いどころか、コメントすら自動生成してくれる

自動生成のコメントになんの意味があるのやら。

見た目っすか？ｗ

>>842
コードを書く → コメントを書く → リファレンスが生成される

PHPに限らず、一般的なワークフローだけど？
まぁ、業務開発やオープンソース開発をしていないなら不要かもね･･････

酷い自演を見た気がする今日この頃

スレ伸びてるから何かと思ったら・・・・

今月のスルー推奨ワード

・phpStorm
・phpdoc
・アノテーション
・IDE

上記の話題をしたい奴はスレタイ10回読んだ後で
他のスレでやってくれな

phpdocとかアノテーションとかどうでもいいが
IDEと親和性の良いフレームワークの情報は需要あるだろ

教えてえろい人

>>846
お前>>837=838=840=841=843だろ
それが既にスレ違いだって言ってんだよ

＞IDEと親和性の良いフレームワークの情報は需要あるだろ

フレームワークと相性の良いIDEってんならまだ話は判るけど逆だろ
なんでIDEありきでフレームワーク選ばなきゃならんのよ
どうしてphpStormに話題を持っていきたいのか知らんけど
IDEについて語りたいなら自分でスレ立ててそこでやれよ

ついでに言うとアノテーションで必死になってたのもお前だろ
文体が一緒だわ。()で括って補足書くとことかな
ID出ないから自演してんだろうけど、うざいから程々にしとけよ

>>847
フレームワークと相性の良いIDE聞く方がスレ違いだろ、、、

IDEを使うと >>838 のようなフラストレーションは出てくるんだよ
cake 1.xとかで $this->model->【補完出来ない】　みたいな事とかさ
俺としては話題の軌道修正したつもりだったんだが、すまんな

文体が一緒？別人なのに不思議だね。

可哀想だから一応聞いておこう
>>847 様のオススメのフレームワークとその理由を是非ご教授ください＞＜

FuelPHP

>>828
phpunitの@xxxも、アノテーションって言うよ。
http://phpunit.de/manual/current/ja/appendixes.annotations.html

顔真っ赤だな

纏めるとPHPerはIDEがないとFW使えないって事でおｋ？

>>835
FW初心者が学習コストをかけずに簡単なサイト構築に使えるのがメリットだと思うんだけど
マイクロフレームワークを独自に拡張してあれこれやるのは本末転倒だろうし

マイクロフレームワークは割り切って使うには良いんじゃない？

簡単な問い合わせフォームを作る時とか
既存CMSカスタマイズするより楽だし、汎用知識として身につくし、選択肢としては悪く無いと思う

IDE云々みて思うのは、静的な型じゃないという言語欠陥を補うのはとてもしんどいってことだな
個人で開発出来る規模を超えてチーム開発が必要になるようなら、素直に別言語メインにしたほうが捗る

これだけじゃスレチだからフレームワークについても
結局新しいものがでても、既存の知識しか持ち合わせない不勉強層が
新規FWとかに難色を唱えて騒ぐから、新しいFWを採用すること自体業務でコーディングする上では難しいんだよな
結局俺々か、cake、symfony使ってるとこが殆どな状況、PHPが今まで以上にもっと下火になるまで続くと思うわ
その頃には新しいFWが出なくなってそうだけど

>>956
うちと状況が似てる
チームワークに新しいのを持込むの難しいよねぇ･･･ＣａｋｅＰＨＰやＳｍｙｆｏｎｙxが蔓延してる。
不勉強層は学習コストと、自分たちに実績が無いから責任は取らない！と頑なに新しい技術は拒否する。
少しでも開発効率を上げるって名目で、ＩＤＥ導入は自由になったけど、改善にはならんな

その状況で導入してみたいＦＷとか使ったＩＤＥとか聞いていい？

IDEの情報が出ているこの勢いで質問してみます。

上の方でPhpStorm推している人がいますが、誰か他に使っている人いますか？
3年前ぐらいに一度試してみたんですが、しっくりこなくて早く見切りをつけてしまいました。
Eclipse→NetBeansときて今に至るんですが、これらと比べてどうなんでしょうか？

>>858
私も今はnetbeans一本です。
これよりいいのに出会ったことがないです。

俺仕様に拡張しまくりたいならAptanaStudio使えお(´^ω^`)
php初心者に易しいMVCフレームワークを探してるならCodeIgniterから始めろお(´^ω^`)

AptanaStudioってベースはEclipseなんだよな・・・うん・・・

DW→秀丸→phpeditor→NetBeans→Aptanaな育ちなもんで、2chでEclipseがどうして悪く言われているのかよくわからなくてごめんお(´^ω^`)ゞ

開発環境を変えた理由をそれぞれ教えて！
総じてどれが良かったかも。

昔いた会社でZendStudio使ってたけど、途中からEclipseベースになったな
だったらEclipse+PDTでいいだろッて思ったわ
たいした機能もないのに金とろうとするうえに、ベース部分のアップデートは本家よりも遅い

862を見るに、Dreamweaver(だよね？)が入っているのでWebオーサリング機能が欲しいのでしょう
まあ個人的にはいらんな

Aptana ･･･ 一度PHPサポート打ち切られ、選択肢から外れた
Eclipse PDT ･･･ 全体的に優秀。重い＆環境設定が面倒。
Netbeans ･･･ 軽いしUIが日本語でとっつきやすい。若干コード補完が弱い。
phpStorm 5以降 ･･･ 有償。PHPとJSのコード補完が飛び抜けている。
ZendStudio 7,以降 ･･･ 有償。PDT上位互換、重い以外の不満は特に無い。

>>765
Zendかぁ・・・
これ以上を求めると、一気にガチガチになっていくのかな

そんなにコード補完必要か？
俺はSublime Textの補完程度で満足してるが。

フレームワークを使ってそれなりの規模のシステムを作ることになると道具の違いが快適さに直結する
テキストエディタの補完機能なんて、せいぜい言語構造や標準関数の名称を補完するぐらいでしょう？

>>869
俺宛のレス？

> せいぜい言語構造や標準関数の名称を補完するぐらいでしょう？

どの程度を想像してるのかわからないけど、いろんな言語でいろんな補完ができる。
https://www.google.co.jp/search?q=sublime+text+2+%E8%A3%9C%E5%AE%8C&oq=sublime+text+2+%E8%A3%9C%E5%AE%8C&sourceid=chrome&ie=UTF-8

でも、例えば「$this->add(」とか打つと引数のプレースホルダを補完したりするエディタあるけど、
それほど便利とは思わないんだよね。いる？これ。

>870
「$this->add(」とか打ったときに思っていた候補が出てこないと、「あれっ、なんかミスった？」と見直すことはよくある。

vim使ってるので、補完はomniくらいだが不便とは思わない。

複数人で並行開発するようになるとバグを大きく減らす自動補完は工数の削減に大きく影響する

()みたいに閉じ括弧も一度に入力するので、
閉じ括弧を補完するやつなら大迷惑

>>874
『(』を入力した時点で『)』が出てくるんだけど、
そのまま『)』を入力しても上書きされておかしなことにはならない。
NetBeansではそうなってる。

エディタとしても便利だけど、負の遺産コードを読むツールとして便利だよ＞最近のIDE
HTMLやSQLやJSが混在していても、それぞれの定義元に飛べたりするし。

>>870
Sublimetext は文脈を解析しての補完はしてくれなくね？

$hoge = new Hoge();
$unknown = $hoge->getHogeeeee(); .// 戻り値も定義元も不明

の後に

$unknown->

とタイプすると、どこまで補完してくれるんだろ。

延々とIDEの話してる奴はスレタイ読めないアホなの？

IDEも大きな視点で見ればフレームワークの一環だよね

>>875
「)」が邪魔になる例としては http://jsdo.it

>>876
そんな補完してくれなくていいよ

<?php
って打ったら俺の仕事が全部補完されてるIDEを教えてください(*´艸｀*)

同僚の井出さんは、すっごい仕事のできる人で、プログラミングのみならず全て補完してくれます。
ただし有料です。

オチがわからない・・・解説たのむ。

井出 = I DE

だろ？

>>880
補完はどうでもいいけど、定義元が解るのは他人の書いたコードを読む時に捗る

CodeIgniterはMVC初学者にとっては良い学習用フレームワークである
いまどきのフレームワークはComposerを使った外部ライブラリと依存する方向へシフトしてきている
それに加えて、開発元はCodeIgniterを手放そうとしている
CodeIgniterに未来は描けなくなった
もはやCodeIgniterを選択するべきではない

では、何を選択するのがよいか？
中規模 CakePHP|Laravel|FuelPHPのいずれか
大規模 Symfony

長いものにまかれるためにSymfony2使ってる。
国内だと1.xがまだ現役ぽいけど

Symfony2 どうよ？
個人的にCLIツール群はいらんのだけど、ビジネスロジック部実装するにあたって便利だなぁって思う機能ある？

仕事でやるならCLIになれとかないと

CodeIgniterは、開発元とか将来性とか気にするほどのものじゃないだろ
興味があったら使えばいいし、嫌になったらやめればいいし、気軽に使えよ

CLIで作業する事はあってもsymfony コマンドとか使いたくねぇなぁ

Rainってどうなの？
http://www.rainframework.com/
テンプレートは使いやすかったけど。

>>892
エラーでまくり

PHP5.5に変えてから、pearライブラリで、
「Fatal error: Call-time pass-by-reference has been removed in 」が
頻出するようになった。修正が面倒くさい。いい方法ない？

PEAR パッケージ のアップデートじゃない？
種類によっては修正パッチみたいなのもあるようだけど
http://pear.php.net/bugs/bug.php?id=19773&edit=11

>895
なるほど。ありがとうございます。早速アップデートしてみます。

久しぶりに来たら、CakePHPのスレってなくなってる？

composer使っている人いる？

fuelPHP使ってると、コンポーザー使わざるを得ない

fw自体の更新も楽だからcomposer使ってる

iphone用の画面に特化したのがほしい

LichKing使ってる人いる？

もぅCakeはいいだろ・・・

Cakeがいやならパンを食べればいいじゃない

いいねえ今度のFWの名前が決まったな

マリーアントワネットフレームワークか。

マリー・アントワネット・ジョゼファ・ジャンヌ・ド・ロレーヌ・ドートリシュ フレームワーク

PanPHPだな。

BreadPHPだろ、ってツッコミいれたら負けですか？

bakeコマンドはそのまま使えますね

パンが無ければクッキーを焼けばいいじゃない

秒間4億枚くらい

BbaPHP です

CookiePHPとかありそう

cookieとか ややこしいだろ

CookiePHPは紛らわしいからCookieClickerPHPにすれば良いね

おれおれCookieClickerが簡単につくれるそうでいいね

つくれるそうって誰からの伝聞だ

クーキーはbbaがつえーからなぁ

最近 Curry というフレームワークの存在を知って、
気に入って使い始め、ある程度作りこんだ矢先に本家ウェブサイトが消えてしまった。
作者様の身に何があったのかは分からないけど、マイナーなフレームワークは
こういうことになると、情報の参照先が完全になくなるから困っちゃうな。
作者様、これ見てたらどうか復活してください。

>>918
それはフレームワークに使われてる
段階だからだめなんだよ。お前の技術不足。

まずフレームワークはどれも対して変わらない。
ステートフルなフレームワークみたいに発想そのものが違うものはあるが
同じ発想で作られているものは基本的に同じ。
機能が実装されてるかまだ実装されてないかの違いだけ。

だから長く使われそうなフレームワークを選ぶべき。

もちろん、いろんな事情でマイナーなフレームワークを使うことが
ダメとは言わないが、その場合はフレームワークに依存しないように作るべき。
つまり、今回、お前がやらなければならなかったこと。それが出来ないのはお前の技術不足。

フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
抽象化しておくするべきだ。そしてコアの部分はフレームワークに依存させないように開発する。
それが出来るように、技術を磨けよ。

>>919

しかと受け止めました。
親切にありがとうございます。感謝です。

>>919
> フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> 抽象化しておくするべきだ。

ムリムリ

それ以前にフレームワークを更に抽象化させようとする意図が掴めない
実際にZend Framework/Symfony/CakePHP/FuelPHPに対する具体的なコードを見せてもらいたいな

フレームワークを抽象化するフレームワークですね解ります

>>921
お前には無理なの？
そうか、そうなんだね。

>>922
フレームワークを抽象化させてどうするのさｗ
誰もフレームワークを抽象化するなんて言ってないし。


ヒント、デザインパターンより

・Adapter パターン
互換性のないインタフェースを持つクラス同士の接続を可能にします。

はずれのFWを選んだってだけのことだろう

>>925
フレームワークが用意した仕組みを無視して
自作のラッパークラスを使えって事？
アホくさい

>>927
だからお前は馬鹿なんだ。

Adapterって言ってるだろ、
フレームワークが用意した仕組みを使うからこそ
Adapterなんだってわからんのか？

>>928
s/仕組み/API/
これでいいか？

フレームワークが用意したAPIを無視して
自作のラッパークラスを使えって事？
アホくさい

まぁ言葉遊びとかどうでもいいから具体的なコードを見せてくれ
自分が知ってるフレームワーク間だけのでいい
こっちはあんたの理想とやらをどう具体化してるのか知りたいんだからさ

>>920
だからさAdapterを使う＝フレームワークが用意したAPIも使う
という意味であるということを、理解できてないのはなんで？

あんたは話をする最低レベルにすら到達してないんだけど？

>>930
Adapterパターンって言ってるだろ。
それでわからんのか？

つーかさ、ユニットテストどうやってるのさ？
お前の作ったアプリは、当然ブラウザなしでも
メインの処理行えるよな？
（ユニットテストでは通常ブラウザは使わない）

あとは、そのメインの処理をフレームワークと
つなげるAdapter作るだけじゃん
最低限度の基礎知識さえ知ってれば、わかることだよ？

>>932
悪いがエスパーじゃないんでね
Adapterで何と何を繋げるんですかね
コード出してくんなきゃ話が進まないんだけど

> メインの処理をフレームワークと
> つなげるAdapter作るだけじゃん

読めないの？ｗ

>>935
> コード出してくんなきゃ話が進まないんだけど
読めないの？

>>936
出すつもりはないよ。

だから、最初っからヒントって書いただろｗ
自分で考えろって意味さ。

>>937
コードはもういいけどよ
言葉遊びは止めろつってんだろ馬鹿野郎
Adapterは実装手段であって目的じゃねぇんだよ馬鹿
APIの差異を吸収するレイヤーを作れとなんで一言で表せねぇんだよ
アプリケーションへのHTTP Requestを表すオブジェクトに対するAPIを例にしたらこうだろ？

+----------------------------------------------
|　　　　　　　　　　　アプリケーション
+-----------------------------------------------
|　　　　　　　　　　 オレオレRequest API 　　　　　　　　　　　
+---------------------+---------------------+--
| Symfony 2#Request API | CakePHP#Request API | ..
+-------------------------------------------+----

このオレオレAPIを挟むのがアホくさいってんだよ
ボトムアップで機能を殺していくアホの設計
知識の共有化をスポイルするアホの所業

> Adapterは実装手段であって目的じゃねぇんだよ馬鹿

いつAdapter が目的だといった？
お前本当に馬鹿じゃないのか？

> このオレオレAPIを挟むのがアホくさいってんだよ
その図を考えたのは誰だ？
おまえだよな。

その図は間違いだ。
つまり、お前は間違いを書いたんだ。

アホ？ アホはお前だろう？

> APIの差異を吸収するレイヤーを作れとなんで一言で表せねぇんだよ

「APIの差異を吸収するレイヤーを作れ」と言うわけがないだろ。
そんなもん作らないんだから。

本当にアホだなぁｗ

>>939-940
じゃAdapterをどこで何に使おうと思ったのかな？
あ、コードを出す気はないし答えも言わないんだったな
もう1人で後出しジャンケンやっててくれや

>>941
もう触るな。Adapterの意味すらわかってないよきっと

>>938
普通にフレームワーク使ってても、拡張すると俺俺層が出来てくるだろ？

MVCガッチリかみ合ったフルスタックFWを、他のFWに置き換えるのは相当しんどいけど、
一部機能を載せ替えるのは案外楽だよ。

アダプタでもいいし、プラグインでも拡張でも、何でも･･････
ただ意味があるのかどうかは知らん。

>>943
> 普通にフレームワーク使ってても、拡張すると俺俺層が出来てくるだろ？

何のフレームワークを使ってて、どの部分にどんな俺俺層ができるの？

>>943
俺俺層自体を否定してませんよ
拡張のために自分も普通に作りますからね
でも「FWの移植に備えるため」には用意しません

アダプターを介して使えと言われた側はそれで済むから別にいいです
で、移植する先のアダプターを用意する人は誰なんですか、結局自分でしょ？
そのアダプターは移植する前の機能を備えていないといけない、移植先でも動くようにしなければいけない
移植する未知のFWがどんな設計なのかも分からないのにできるんです？
モデル/ビュー/コントローラー/データベースへのインターフェイス/マイグレーション/コードジェネレーター/etc...
出来たとしてもキリがないですよ
そしてFWに変更があれば「自分のアダプターも更新しないといけない」、やる気になれないでしょ…

銀の銃弾みたいに抽象化だのアダプターだの言ってるから
どう対応するのか、どう設計するのかを知りたかったんですけどね
口先だけの人みたいだからがっかりですわ

未来永劫、一人で開発してメンテナンスもするということが確実なら、趣味で膨大な俺俺層を作ってもかまわないけど。

新しい言語を覚える必要の無いフレームワーク ってある？

>>945
えとさ、お前の書いたアプリのメインロジックって
なんかのフレームワークに依存しちゃってるの？

普通POPO（Plain Old PHP Object）で作るよね？


もしメインのロジックまでフレームワークに依存していたら
やばい。フレームワークを乗り換えることもできないし
フレームワークが死んだら大変なことになるよ。

素人がFWを使うより、玄人が作った俺俺コードの方が遙かに保守性が高いし、
長期運用考えるならFWのメンテナンスより、DB設計や機能単位の切り分け設計の方が遙かに大事だ

> 素人がFWを使うより、玄人が作った俺俺コードの方が遙かに保守性が高いし、

不要な単語が多いので重要な点だけ抜き取りますね。


> 素人より、玄人の方が遙かに保守性が高いし、

当たり前じゃね？

玄人＋FW　　＞　　玄人＋俺俺 　　＞＞＞＞＞＞　　素人＋FW≒素人＋俺俺

まあ当たり前の話だよ。

当たり前だよな

でも、PHPのFW使いの大半はプログラマとして素人だ。
だからPHPerは質が低いと馬鹿にされる。

上でアダプタパターンが云々言ってるアホがいるけど、
中途半端に解った風になったPHPerが一番恐い、糞コード生成マシンになる

traitsとか使い始めたら世界は崩壊する

訂正

×でも、PHPのFW使いの大半は
○>>952とその仲間たちはプログラマとして素人だ。

誰かと思えばBootstrapスレで暴れてたキチガイじゃねぇか

>>954
つまりあなたは両方のスレで暴れているということですね？

今度はフレームワークをセマンティックしに来たか

なんか他のスレで暴れていた奴が
こっちに逃げてきてるな。

こっち来んな。はげ

>>948
俺はフレームワークに躊躇なく依存するよ
普通と言うなら基本的にフレームワークが用意しているベースモデルを継承して
そこにビジネスロジックを書くのが普通なんだけど
RailsでもDjangoでもフルスタックのものは大抵そのスタイルだしね

POJOを持ち出すからそれについても突っ込むけど
Java界隈じゃ継承の代わりにアノテーション使ってるだけでやってる事は変わんないぜ？
結局はそれを解釈するフレームワークに依存してるんだしな

継承はベースクラスがないと
クラス単体で使えない。

アノテーションはベースクラスが不要

この点でぜんぜん違うわけだが？

> 俺はフレームワークに躊躇なく依存するよ
具体的に、どのフレームワークの
どのクラスに依存するのか書いてみ。

念の為に言っておくが、ロジック、
つまりモデルの話だぞ。

お前のモデルはなんのクラスを継承するのだ？

>>958
>>960
ビジネスロジックがFW依存するのは、FWと共に命運を共にするなら有りじゃね？

そもそもベースモデルが存在するFWって何よ？
大抵はモデルという名のORM実装じゃねぇ

>>959
クラス単体で動くアプリですかそうですか良かったですね

>>960
ごめん、FWみんながモデルの継承を強要されてるみたいなおかしな書き方をした俺が間違ってる
継承してるのは逆に一部だ
Symfony 2はDoctrineでアノテーション式、
Zend FrameworkもFuelPHPも自前のマッパーやらアダプターを任意で使える

CakePHP 2 : http://api.cakephp.org/2.3/class-Model.html
Rails: ActiveRecord::Base
Django: django.db.models.Model

そもそも確認するけど、俺はビジネスロジックに
データベースへのアクセスも含まれる認識で話してたんだけどあんたは違うのか？
MVCの、モデルの、更にその一部、そこだけ切り取って「はい移植性高い」なんて喜んでる話だったの？
だとしたらやっぱやるだけ無駄だわ

>>961
ORMでもなんでもいいよ
ビジネスロジックがどうのとかモデルはこうあるべきなんて焦点にしてないから
俺の主張はフレームワークが決めた方法に従え、
移植のために小細工なんてせずに使えって事だ

>>960
> 念の為に言っておくが、ロジック、
> つまりモデルの話だぞ。
なんでここまで後退してるんだ？

そもそもの話は>>919
> フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> 抽象化しておくするべきだ。

であり、それを実現するために、>>925
> ・Adapter パターン
を使えということだった。

「フレームワーク部分を比較的簡単に取り替えられるように」するためには、Modelのみならず、
当然Controller/View部分も対応しておく必要がある。

>>962
＞俺の主張はフレームワークが決めた方法に従え、
＞移植のために小細工なんてせずに使えって事だ
そこは同意する。

ただ俺が言いたいのは、
Cake, Rails, Djamgo等、君が挙げているフレームワークはＯＲＭやＤＢ操作クラスを「モデル」と定義しており、
闇雲に従ってしまうのはよろしくないと思う。

時々素人が「このロジックはControllerに書くべきでしょうか？Modelに書くべきでしょうか？」と聞いてくるけど、
FWでモデル＝DB操作クラスと定義されている為、DBを必要としないロジックを書く場合どうするのか無駄に悩んでしまうんだろうね。

これは、DB操作クラスを内包する本来の意味でのモデルを作るのが正解だと思う。
俺はCakeを使う場合 CakeMdodel(DB) ⇔ 俺俺モデル ⇔ CakeController という方法で実装している

>>964
> 俺はCakeを使う場合 CakeMdodel(DB) ⇔ 俺俺モデル ⇔ CakeController という方法で実装している

糞実装の見本

>>965
お前がモデルを理解していない事だけはわかった
黙ってBakeしてろ

>>964
それ、俺俺モデルの内容をCakeModelで実装すればいいだけじゃないの？
分離するとclass loaderとか面倒なことになりそうな気がするが、それを上回るメリットは？

俺俺モデルというか、AppModelを継承して、Cakeの枠組み内で実装すればいいんじゃ？

つか、CakePHPのModelのありようが気にくわないならCakePHP使うなって話だな

>>964
フルスタックなFWを使うのをやめれば解決。

>>964
そういう話なら、Rails界隈でさんざん議論されてきたことで、例えば
『Rails のモデルはどうあるべきか』
http://tomykaira.hatenablog.com/entry/2013/07/05/231752
とか読む方が、お前の稚拙なコメントよりよっぽど役に立つ。

>>967
>>968
Cake の AppModel & Model の内部実装見た事ねーだろ？
あれはモデルじゃなくてDB抽象化クラスだ。
class loaderは命名規約守ってれば何1つ問題無いけど、何が問題になるの？

>>969
何か勘違いしてねーか？
CakeがDBアクセスクラスをModelと命名してしまったせいで、
MVC本来のModelとして俺俺モデル作ってるだけだよ

>>964
済みませんがモデルについての是非は別の人とオナシャス
アプリ実装者や各FWがモデルをどう考えてどう設計してるのかには俺も興味あるけど
移植性の話から逸れるしｗ

RailsやCakePHPのModelが、MVCにおけるModelとは違うというのは既知の話題。
で、どう実装すべきかというのは>>971にもあるようにさんざん既出。

そういうのはもうどうでもいいので、
>>963
> そもそもの話は>>919
> > フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> > 抽象化しておくするべきだ。
に対して意見がないなら、もう黙ってくれる？

そもそもCakePHPがDBアクセスクラスをModelと命名したんじゃなくて、RoRをまねしたから似たような役割になっただけ

CakePHPのModelが駄目駄目だと見破った俺すげー自慢

>>973
>>974
ああすまん、話逸れてたね。

> そもそもの話は>>919
> > フレームワークが消えそうならば、フレームワーク部分を比較的簡単に取り替えられるように
> > 抽象化しておくするべきだ。

個人的には「無し」だな。
フレームワーク差し替えを考慮するなら、昨今のフルスタックフレームワークを採用するべきでは無い。
アダプタにしろ何にしろ技術的に不可能では無いが、どう考えてもコストもリスクも見合わない。

というか取り替えるシーンが全く思いつかないｗ

>>962
> データベースへのアクセス

データベースへのアクセスに使うのはライブラリであって
フレームワークじゃないよ。

Railsが馬鹿なんだけど、モデルがActiveRecordを
継承するという設計は間違い。

モデルはActiveRecordを使うが、
モデルはActiveRecordではない。

http://d.hatena.ne.jp/k-sato_at_oiax/20100722/1279803193
> ActiveRecord の後継と目される DataMapper では、継承を使わずに Mix-in を採用していますね。
> 継承を使いすぎたという反省が、Rails 業界にあるんじゃないかと思います。
> 他にも、MongoDB 用の mongoid も Mix-in アプローチを採用しています。

まあだいたい継承し過ぎでやめましょうってなるのは
どのフレームワークでも一緒ｗ

Javaが遠い昔に通りすぎた道。
そしてPOJOにいたる。

未来にはよ来い、PHPフレームワーク使いｗ

>>979
素人がtraitを覚える
↓
フレームワークの使い方がよくわからない＞＜
↓
traitで拡張しよっと（＾ｐ＾)俺スーパープログラマだ
↓
カオス

継承より委託にシフトしてった理由は、単純にテストでの優位性ってのがでかい
継承がダメっていうか、委託するように作っておけば、依存性を注入出来るようにも記述できるから
テスト対象ロジックと対象外ロジックの切り分けがしやすくなる

抽象化ができる部分の継承は悪ではない

馬鹿のいる職場で、データアクセスのライブラリの例外処理の隠蔽や機能制限のためにラッパー噛ませることはあるけど、
フレームワークそのものにラッパーとか何のメリットもないな
再発明とテスト工数の増大を引き起こすデメリットしか見えてこない

>>978
そのフレームワークに実装されてるライブラリを使ってたら
いっしょじゃね？

委譲を委託と言う奴の言うことなんか聞かないし

delegateのことを委託っていう人もいるみたいよ
でもまあ文脈からして委譲の方が正解な気がするけど

>>918
このページは「本家」じゃないの？
http://www.curryfw.net/index

最近も更新されてるみたいだが。
2013-09-08　　Curry ver.1.4.10 リリース
2013-08-31　　Curry ver.1.4.9 リリース
2013-06-10　　Curry ver.1.4.8 リリース

>985
日本のカレーは本家じゃないでしょ

>>978
例え話って話が逸れるから嫌いなんだけどさぁ…
さんま焼き定食に味噌汁がついてくると仮定するでしょ？
別に味噌汁が無くたって成立するけどさぁ
お店がセットで出す限りそれはさんま焼き定食という集合の一部じゃん
さんま焼き定食と言う名の集合に味噌汁を含めるか含めないかなんてお店次第じゃん？
これフレームワークとして置き換えてみたら
ライブラリは味噌汁、コンソールやらツールやらはおしんこって感じにならね？
じゃあさんまは何になるんだろうな

ってずれていくから例え話は嫌なんだよなぁ
でもその主張はおかしいと思うんだよな

>>986
Curryの作者って日本人じゃないの？

Curryを作ったのが誰かわからないが、
・http://www.objective-php.net/ の記述
・Curry本体のファイルのCopyrightが"www.curryfw.net" になっている
ということから、http://www.curryfw.netは本家で、作者は日本人だと思う。