どちらかというと技術よりＦＷのルールを理解するのがアレなのよね

本当に大規模で今後長期的に運営するサービスとかなら、
独自FW開発するコストも相対的に下がるし、
外部プロダクトに依存するリスクも減らせるから
オープンソースFW採用しないのも理解できるけど
>>631 みたいな理由はよくわからない。

ただ「学習コスト」に対する心理的な部分では、
PHPそのものの言語仕様に対する「学習コスト」に比べて、
他人が作った枠組み・制約に合わせることを「学習」することに
なんで俺様が時間を割かないといけないんだよ？
みたいな壁があるのは否定しない。

著名人が作ったFWには説得力はあるよね

FWを利用すれば、最先端のプログラム作法が、
苦労せず身につく

高度なプログラミングの方法論を大学へ行って
学ばなくてもみんなが共有できる

著名人が作ったFWっどれ？

使いたければ使えばいい、そんなもんでしょ
アンチしたけりゃ専用スレ立ててやってほしいわほんと

CodeIgniterというのが良さそうですが、
日本語の資料が少ないこと以外に
何か欠点はありますか？

日本で普及する可能性は低いでしょうか。

普及してるかと。

というか、どんなものを作るのか明示しないと
誰もそのツールが的確か判断できないよ。

>>659
もう普及してるんですか。

得意不得意があるとは思わなかったので、
作るものを書きませんでした。すみません。
ECサイト、CMSや、小さいものだと
ちょっとしたツール（社内で使うようなもの）です。

復旧の度合いにもよるけど、FWの中では知名度はあると思う。
ダウンロード数で比べてみるとかどうかな。

CIはCMSには向いてるけど、ECサイトならもっと別の
専用のがあるのじゃないかな。

まぁ少しは調べてここに書いてみてよ。俺はCIあまり知らないしw

>>661
どんな用途でも一つのフレームワークで済ませたいと思ってしまったんですが、
やっぱりいろんなフレームワークを使えるようにしないといけないでしょうか。
調べてみると、CodeIgniterは比較的取っ付きやすいようなので
とりあえずやってみます。
ありがとうございました。

PHP4対応のフレームワークを今から使うのは個人的には敬遠したい
慣れの問題かも知れないけど

PHP5非対応なわけじゃないから、別にいいんじゃない？
それともPHP5で使うと何か問題ある？

もうrailsでいいんじゃないかな

>>658
CIは俺も好きだが今からやるもんじゃない

PHP5.3のメリットをしっかり生かしてるFWがあったら5.3での開発手法の参考にしたいんだけど
オススメは？

>>668
しっかり生かしているかとなると疑問だけど、Zendがいいかも。
ただ、どのFWも『PHP』のメリットを生かせてはいない感じだよね。

PHPなら$_GET/$_POST/$_SESSIONを使えるのがメリットだと思うし。
まあ、デメリットでもあるのかもしれないけど。

yiiはどうだろう

CodeIgniterについて引き続き調べたら、
セッションデータが丸ごとクッキーに保存されるとかなんとかで
あまり良くないとわかりました…。

代わりに、CodeIgniterをベースにして改良されたKohanaというのが良さそうです。

日本語で解説してるのほとんどないぜ

>>669-673
ありがとうございました

>>672
>CodeIgniterについて引き続き調べたら、
>セッションデータが丸ごとクッキーに保存されるとかなんとかで
>あまり良くないとわかりました…。

え、クッキーセッションがなんでだめなの？

>>676
POST/GETと違いデータがクライアント側に渡らないのがセッションの利点の一つなのに
セッションIDだけでなくデータもクッキーに入るのが嫌って意味でしょ
RoRではデフォルト。

>>678
ModelというのはActiveRecordだと考えていい？
とすると、俺の場合はmodelsの下にCommonModel.phpとかを作って、
各々のモデルクラスではCommonModelを継承させてる。

他のアプリケーションにも使いまわせそうな処理なら
CActiveRecordBehaviorを使ってみることを検討するとよりいいかも。

>>679
なるほど、標準では共通的なメソッド等を書くファイルというのは
決められていないようですね。

正攻法っぽいbehaviorを検討してみます。

ありがとう。

こんにちは。Rasmus Lerdorfです。

名スレの予感

>>681
クソ言語なんか作るんじゃねぇ！

>>682
Rasmusです。Matzさん、ご無沙汰しております。
その後ご機嫌いかがですか。

>>677
>POST/GETと違いデータがクライアント側に渡らないのがセッションの利点の一つなのに

えと、なぜそれが利点なんでしょうか。渡ると何か不都合がありますか。

改竄

盗聴

>>685
クッキーセッションでは、SHA1などをつかったハッシュ値と、サイトごとの
秘密キーを使って、改ざんを検出している。
だからそれをクッキーセッションの欠点とするのはおかしい。

>>686
それを心配するなら、クッキーセッションじゃなくてもセッションIDが
盗聴されることになるので、やはりクッキーセッションの欠点ではない。

$_SESSION['pass']='hoge';
と
setcookie("pass", "hoge");
の差は明らかだと思うぞ

ところで$_COOKIE['pass']='hoge';って書き方できるの？

PHPは組込みでセッション機能持ってるんだから、それをそのまま使った方が良いと思う。
オブジェクトにする必要性もあまり感じない。
ファイルハンドルを透過的に保存復元したいとかかな。
確実に処理が遅くなるってデメリットに対して、大きなメリットを感じない。

>>690
>ファイルハンドルを透過的に保存復元
これの意味がわかんないけど、
俺は複数台サーバ構成の時とか、セッションのDB対応とかの時にメリットがあると考えてる。

>>691
> 複数台サーバ構成の時とか、セッションのDB対応とか
これって頭の中では同じ事想定してないか？

セッションのDB対応も、結局はPHPの関数インターフェイスを利用するわけで、
はてはレプリケーション対応のため強制的にマスターDBをアクセス対象にする
設定とかもその中で可能なわけで…

それを「クラス」でやるか、なんかしらん「インクルードファイル」でやっちゃうか、の
違いでしかないと言われればそこまでだよなあ、と思わんでもない

どっちかっていうと、PHPが準備していない、「セッション名前空間」的な、
仮想的な上乗せ機能の方にメリットを感じるなj

共有ディレクトリを使うか、session_set_save_handler()で入出力処理を書けば良いだけ。
ファイルハンドラは普通にやってもシリアライズ出来ないから、ユーザがアップロードしたファイルを画面遷移しつつ引き回そうとすると、単に$_SESSIONに値を入れるじゃ済まない。
しかし、ほとんどのフレームワークって$_SESSIONをラップしてるだけだろう？

>>693
アンカつけような。
おまいが言ってることの大半は>>691向けか？
>>692ですでに半分くらい言われてるぞ

大体、ファイルハンドラのシリアライズ・引き回しって何だよ。
やるとして、受け付けたファイルの「中身」をDBなりなんなりで
持ち回すしかないんじゃね？ハンドラ？

PHPの場合、セッションが標準インストールで組み込まれている。
ウェブサーバ分散とか、ローカルファイル以外への永続化とか、十分な機能を持ってる。
だから、自前でセッション機能を実装する必要性はほとんどない。
また、セッション変数はスーパーグローバルになってて、その実態は単なるハッシュだが、それで困ることもほとんどない。
ただ、ファイルハンドルみたいなリアライズできないデータは、単なるハッシュへの代入では済まされない。
シリアライザの問題であるけど、データ型に関わらず透過的に保存できるならその方がいいし、そうするとセッション変数をオブジェクトにしてその処理を隠蔽する必要が出てくる。
とはいえ、そんなケースは滅多にないかな。

ここで最大の問題は、>>691がPHPの標準セッション機能では「複数台サーバ構成の時とか、セッションのDB対応とか」出来ないと思ってる事にある。

世界最軽量mvcフレームワークありましたらどなたかおしえてください

>>697
http://php.cheetan.net/

ひさしぶりだなちぃたん。元気してた？

気軽で軽量なPHP5FWないかねえ
cakeやzendなんて余分すぎる