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"