元スレ【PHP】PHPフレームワーク総合スレ14
php覧 / PC版 / みんなの評価 :
前へ
651 = :
どちらかというと技術よりＦＷのルールを理解するのがアレなのよね
652 = :
本当に大規模で今後長期的に運営するサービスとかなら、
独自FW開発するコストも相対的に下がるし、
外部プロダクトに依存するリスクも減らせるから
オープンソースFW採用しないのも理解できるけど
>>631 みたいな理由はよくわからない。
653 = :
ただ「学習コスト」に対する心理的な部分では、
PHPそのものの言語仕様に対する「学習コスト」に比べて、
他人が作った枠組み・制約に合わせることを「学習」することに
なんで俺様が時間を割かないといけないんだよ？
みたいな壁があるのは否定しない。
654 = :
著名人が作ったFWには説得力はあるよね
FWを利用すれば、最先端のプログラム作法が、
苦労せず身につく
高度なプログラミングの方法論を大学へ行って
学ばなくてもみんなが共有できる
655 = :
著名人が作ったFWっどれ？
657 = :
使いたければ使えばいい、そんなもんでしょ
アンチしたけりゃ専用スレ立ててやってほしいわほんと
658 = :
CodeIgniterというのが良さそうですが、
日本語の資料が少ないこと以外に
何か欠点はありますか？
日本で普及する可能性は低いでしょうか。
659 = :
普及してるかと。
というか、どんなものを作るのか明示しないと
誰もそのツールが的確か判断できないよ。
660 = :
>>659
もう普及してるんですか。
得意不得意があるとは思わなかったので、
作るものを書きませんでした。すみません。
ECサイト、CMSや、小さいものだと
ちょっとしたツール（社内で使うようなもの）です。
661 = :
復旧の度合いにもよるけど、FWの中では知名度はあると思う。
ダウンロード数で比べてみるとかどうかな。
CIはCMSには向いてるけど、ECサイトならもっと別の
専用のがあるのじゃないかな。
まぁ少しは調べてここに書いてみてよ。俺はCIあまり知らないしw
662 = :
>>661
どんな用途でも一つのフレームワークで済ませたいと思ってしまったんですが、
やっぱりいろんなフレームワークを使えるようにしないといけないでしょうか。
調べてみると、CodeIgniterは比較的取っ付きやすいようなので
とりあえずやってみます。
ありがとうございました。
663 = :
PHP4対応のフレームワークを今から使うのは個人的には敬遠したい
慣れの問題かも知れないけど
664 = :
PHP5非対応なわけじゃないから、別にいいんじゃない？
それともPHP5で使うと何か問題ある？
666 = :
もうrailsでいいんじゃないかな
667 = :
>>658
CIは俺も好きだが今からやるもんじゃない
668 :
PHP5.3のメリットをしっかり生かしてるFWがあったら5.3での開発手法の参考にしたいんだけど
オススメは？
671 = :
yiiはどうだろう
673 = :
日本語で解説してるのほとんどないぜ
676 = :
>>672
>CodeIgniterについて引き続き調べたら、
>セッションデータが丸ごとクッキーに保存されるとかなんとかで
>あまり良くないとわかりました…。
え、クッキーセッションがなんでだめなの？
680 = :
>>679
なるほど、標準では共通的なメソッド等を書くファイルというのは
決められていないようですね。
正攻法っぽいbehaviorを検討してみます。
ありがとう。
682 = :
>>681
クソ言語なんか作るんじゃねぇ！
683 = :
>>682
Rasmusです。Matzさん、ご無沙汰しております。
その後ご機嫌いかがですか。
684 = :
>>677
>POST/GETと違いデータがクライアント側に渡らないのがセッションの利点の一つなのに
えと、なぜそれが利点なんでしょうか。渡ると何か不都合がありますか。
685 = :
改竄
686 = :
盗聴
687 = :
>>685
クッキーセッションでは、SHA1などをつかったハッシュ値と、サイトごとの
秘密キーを使って、改ざんを検出している。
だからそれをクッキーセッションの欠点とするのはおかしい。
>>686
それを心配するなら、クッキーセッションじゃなくてもセッションIDが
盗聴されることになるので、やはりクッキーセッションの欠点ではない。
690 = :
PHPは組込みでセッション機能持ってるんだから、それをそのまま使った方が良いと思う。
オブジェクトにする必要性もあまり感じない。
ファイルハンドルを透過的に保存復元したいとかかな。
確実に処理が遅くなるってデメリットに対して、大きなメリットを感じない。
691 = :
>>690
>ファイルハンドルを透過的に保存復元
これの意味がわかんないけど、
俺は複数台サーバ構成の時とか、セッションのDB対応とかの時にメリットがあると考えてる。
692 = :
>>691
> 複数台サーバ構成の時とか、セッションのDB対応とか
これって頭の中では同じ事想定してないか？
セッションのDB対応も、結局はPHPの関数インターフェイスを利用するわけで、
はてはレプリケーション対応のため強制的にマスターDBをアクセス対象にする
設定とかもその中で可能なわけで…
それを「クラス」でやるか、なんかしらん「インクルードファイル」でやっちゃうか、の
違いでしかないと言われればそこまでだよなあ、と思わんでもない
どっちかっていうと、PHPが準備していない、「セッション名前空間」的な、
仮想的な上乗せ機能の方にメリットを感じるなj
694 = :
>>693
アンカつけような。
おまいが言ってることの大半は>>691向けか？
>>692ですでに半分くらい言われてるぞ
大体、ファイルハンドラのシリアライズ・引き回しって何だよ。
やるとして、受け付けたファイルの「中身」をDBなりなんなりで
持ち回すしかないんじゃね？ハンドラ？
695 = :
PHPの場合、セッションが標準インストールで組み込まれている。
ウェブサーバ分散とか、ローカルファイル以外への永続化とか、十分な機能を持ってる。
だから、自前でセッション機能を実装する必要性はほとんどない。
また、セッション変数はスーパーグローバルになってて、その実態は単なるハッシュだが、それで困ることもほとんどない。
ただ、ファイルハンドルみたいなリアライズできないデータは、単なるハッシュへの代入では済まされない。
シリアライザの問題であるけど、データ型に関わらず透過的に保存できるならその方がいいし、そうするとセッション変数をオブジェクトにしてその処理を隠蔽する必要が出てくる。
とはいえ、そんなケースは滅多にないかな。
697 :
世界最軽量mvcフレームワークありましたらどなたかおしえてください
698 = :
699 = :
ひさしぶりだなちぃたん。元気してた？
みんなの評価 :
php一覧へ類似してるかもしれないスレッド
- 【PHP】PHPフレームワーク総合スレ15 (989) - [97%] - 2013/9/27 6:00 △
- 【PHP】フレームワークPharonスレ (306) - [75%] - 2022/10/10 20:00
- 【PHP】フレームワークMapleに舌鼓 (470) - [62%] - 2017/12/31 9:31
- 【PHP】フレームワーク Akelos (129) - [59%] - 2019/5/9 7:46
- 2ch有志がPHPフレームワークを作るスレ (81) - [55%] - 2019/5/9 7:46
- 【PHP】Laravel【フレームワーク】 Part.4 (460) - [53%] - 2021/4/4 4:00
- 【PHP】Laravel【フレームワーク】 Part.11 (870) - [53%] - 2022/8/28 15:45
- 【PHP】Laravel【フレームワーク】 Part.12 (314) - [53%] - 2023/1/30 18:45
トップメニューへ / →のくす牧場書庫について