トップページ⇒php
1001コメント315KB

【PHP】フレームワーク CakePHP　2ホール目

■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん2007/11/14(水) 02:50:28ID:???
本家
http://www.cakephp.org/

10分で作るCakePHPアプリ for Windows
http://p4life.jp/cake/

マニュアル日本語化
http://www.cakephp.jp/doc/

日本語フォーラム
http://cakephp.jp/modules/newbb/

あとこのへんとか（初心者向けTIPS）
http://www.avatarfinancial.com/pages/cake/
0348nobodyさん2008/02/09(土) 23:16:53ID:???
cakeのレベルは落ちないだろ。
0349nobodyさん2008/02/10(日) 01:04:56ID:???
裾野が広がることがレベルが落ちるって事なのか
って事は人気のあるスポーツはどんどんレベルが落ちてるんだな
0350nobodyさん2008/02/10(日) 01:17:48ID:???
あぁ、初心者がたくさん入り込んできて
レベルが下がってるよ。スポーツは
0351nobodyさん2008/02/10(日) 01:37:18ID:???
沢山の初心者がプロの地位をより高めるだけ。
部外者からみてもピラミッドが見えるようにすればいい。
0352nobodyさん2008/02/10(日) 14:24:03ID:???
A hasMany B belongsTo C

こんなリレーションなんですが、A->findAll()すると、Bしか付いてきません。
B->findAll()とすると、Cが付いてきます。

A->findAll()でB,C一緒に持って来たいのですが、どのようにしたらよいのか分かりません。
どなたかヒントをください。
0353nobodyさん2008/02/10(日) 14:24:47ID:???
A->findAll()->findAll()
0354nobodyさん2008/02/10(日) 14:31:15ID:???
ありがとうございます！

A->findAll("","","","","",'3')

これでいけました。
0355nobodyさん2008/02/10(日) 14:37:22ID:???
>349-351
なるほど。なんか納得。
web上ではプロは目立たず素人ばっか目立つから変な感じに見えるのか。
0356nobodyさん2008/02/10(日) 15:35:17ID:???
逆にマイナーなやつだと、それを使用している人は
ごくわずかでそういうものに手を出す人は
詳しい人が多い。

実際は、使う人の問題なのに、
言語の問題といいはるRuby凶なんてのがいたな。
0357nobodyさん2008/02/11(月) 00:25:02ID:???
「プロ」は余裕が無い人が多いからね。
自分が何か情報を出すとライバルに盗まれるかも、とか足を引っ張られるかも、とか思ってるんでしょ。
もうちょっと余裕のある人はちゃんと次を育てていける。
いきなり素人が…とか言い出したりしないだろ普通。
0358nobodyさん2008/02/11(月) 00:28:41ID:???
ホントにプロなら素人と共同作業しないでしょ。

新人には仕事教える立場だし。
0359nobodyさん2008/02/11(月) 02:35:25ID:???
うーん、盗まれるってのは無いと思うけどな。
ネットに限って言えば、プロな人がいろいろ露出するのって、ほぼ趣味なんじゃないか。
PHP界隈が、趣味でやるほどの魅力がない、仕事用の言語って感じだからじゃないの？
0360nobodyさん2008/02/11(月) 02:54:33ID:???
もう作ることではなく、
言語そのものが目的だからなｗ
0361nobodyさん2008/02/11(月) 03:20:56ID:???
言語そのものが目的って、趣味の人だろそれ
0362nobodyさん2008/02/12(火) 08:45:57ID:???
このアソシエーションって擬似的なもん？
一括で更新とかするＳｑｌ文とか作ってるわけじゃないの？
0363nobodyさん2008/02/12(火) 14:38:05ID:???
>>362
複数のテーブルを一括で更新できるか考えてみれば良い。
0364nobodyさん2008/02/13(水) 00:39:35ID:jaUT9mg5
ビューのテンプレートファイルはコントローラによってフォルダ分けされるけど、
単体で使える共用のビューを作りたい時はどうすればいいの？
app/views/common/common.ctpみたいな感じ
0365nobodyさん2008/02/13(水) 01:02:22ID:???
>>364
function common(){
$this->viewPath='common';
}

とかすれば
0366nobodyさん2008/02/13(水) 02:07:27ID:???
element使え
0367nobodyさん2008/02/13(水) 20:01:16ID:jaUT9mg5
>>365
どうもありがとうございます
0368nobodyさん2008/02/14(木) 11:30:58ID:???
ウィザード形式というか、ある項目を入れて次へ→ある項目を入れて次へ
→最後にOKで処理実行のようなページを作るにはどうしたらいいの？

ページごとにエラーチェックしたり、前の入力項目の値を元に
次のページを決めたり、想定外のページ変移に対応したりもしたい。
0369nobodyさん2008/02/14(木) 15:36:54ID:???
>>368
view1枚の中で条件分岐しまくるのはどうか
0370nobodyさん2008/02/14(木) 16:32:15ID:???
viewは一枚としてコントローラ側は？

まあ今はaction一つでやってるんだけど。

なんか一つにごちゃごちゃあって見にくいなぁと
それにページ間での値の参照・共有したいし
なんか良いやり方無いのかなぁ？
0371nobodyさん2008/02/14(木) 16:35:18ID:???
セッションでデータ保持して、ページ移動はredirectとかすればいいんじゃね
0372nobodyさん2008/02/14(木) 16:43:59ID:???
>>371
同感。
03733692008/02/14(木) 16:55:00ID:???
>>370
actionも1個でやる。controller側ではページ分割されていることを意識しない。
1ページ目のpostは、2ページ目以降の項目が未入力と見做してエラー扱い。
表示の調整をviewでやる。

まあ思い付いただけなんで上手く行くかは分かりません。
0374nobodyさん2008/02/14(木) 18:23:10ID:???
それでページの「戻る」とかちゃんと動くのかなぁ？

一ページ目入力、ニページ目入力、三ページ目入力・・・してる途中で
一ページに戻る、一ページ目訂正、
二ページ目はさっき入れたのが表示されているからそのまま次へ。
三ページ目入力

みたいな。
0375nobodyさん2008/02/14(木) 18:27:55ID:???
>>371
> セッションでデータ保持して、ページ移動はredirectとかすればいいんじゃね

汎用的過ぎて参考にならないよｗ

ほぼすべてのウェブアプリはセッションかデータベースにデータ保持して
ページ移動はredirectとか使っている。
0376nobodyさん2008/02/14(木) 18:33:04ID:???
じゃあそれでいいんじゃないの？
03773692008/02/14(木) 19:39:04ID:???
>>374
マイナス1ページはプラス1ページと同じだから問題ないと思うけど、
ページを飛ばすのは処理増やさんといかんなあ。

入力値でページ分岐もややこしそうだ。
あと、未入力エラーを出すか出さないかの判断も必要か。
0378nobodyさん2008/02/14(木) 21:58:46ID:???
セッション変数を使うとして、
いかに管理しやすくするかということかな。
PHP5だと普通にインスタンスをセッション保存できるから、
複数ページで１インスタンスを共有というのもありでしょう。
0379nobodyさん2008/02/15(金) 04:03:48ID:???
ていうか、CakePHPに限ったことじゃないのに悩むとか経験なさ杉だろ。
もっと普通のウェブアプリ作れ。
0380nobodyさん2008/02/15(金) 04:24:44ID:???
>>379
悩まないのならあおってないで答え書いたら？ｗ
0381nobodyさん2008/02/15(金) 06:47:51ID:???
会員ログインID以外のデータを
セッションでデータ保持するのはバカだろ
0382nobodyさん2008/02/15(金) 06:54:30ID:???
>>368
ただの初心者だろ？普通にできるやん
0383nobodyさん2008/02/15(金) 09:08:38ID:???
やん
0384nobodyさん2008/02/15(金) 10:10:41ID:???
>379
いや、Cakeならそのケースでどうするかということで
フレームワークによってセッションの扱いは少しずつ異なるし。
0385nobodyさん2008/02/15(金) 12:21:57ID:???
>>381
んなこたーない
0386nobodyさん2008/02/15(金) 15:43:58ID:???
>>381

俺ほぼ全部を受け渡してるけどな。
だってIDのみだったら他の情報がを表示するときとかっていちいちDBから拾ってくるの？

まぁ、変更するときはDBを更新する必要があるんで接続はするだろうけど。
0387nobodyさん2008/02/15(金) 15:56:24ID:???
全部っつったって、常に表示してるのなんて、名前くらいじゃね？
そのくらいいいじゃん。
0388nobodyさん2008/02/15(金) 16:55:19ID:???
セッションはそもそも大量データを保存するものじゃない
基本的に大量データを引っ張てくるキーだけ保存するもの
0389nobodyさん2008/02/15(金) 16:59:50ID:???
>>386
いちいちＤＢから拾うのが基本
セッションは会員ＩＤなど必要最小限のデータだけ入れるべき
データ大量に保存して持ちまわすものじゃない

0390nobodyさん2008/02/15(金) 17:01:59ID:???
セッションをCakePHPではじめて使う人は
セッションについて何もわかってないみたいだ
0391nobodyさん2008/02/15(金) 17:04:23ID:???
基本的にログインＩＤ以外でセッション変数を多様するのはバカ
0392nobodyさん2008/02/15(金) 17:05:37ID:???
複数のリクエストにまたがる処理の場合、セッションでデータ継続することはある。
0393nobodyさん2008/02/15(金) 17:12:24ID:???
必要最小限以外はhiddenで渡すのが基本
セキュリティ的にもやばいし
ページの前に戻ると不具合がおこりやすい
常に大量データ持ちまわすことはメモリ、ＣＰＵに負荷がかかる
0394nobodyさん2008/02/15(金) 17:14:11ID:???
セッションがダメならcookie使え！
0395nobodyさん2008/02/15(金) 17:18:54ID:???
つーかログインＩＤ以外にセッション多様することなんてないやろ？
ページまたぎ処理はパラメータで引き継げよ
0396nobodyさん2008/02/15(金) 17:27:06ID:???
>>393
>セキュリティ的にもやばいし
どういうとこが？セッション固定化とかは別の話だし

>ページの前に戻ると不具合がおこりやすい
具体的にどんな不具合？
セッションでフロー管理してるからhiddenよりも厳密にできたりするんだけど

>常に大量データ持ちまわすことはメモリ、ＣＰＵに負荷がかかる
大量っていっても、多くても数kとかだし。
何かしらのキーで毎回ストレージから取得するのも処理コストあるよね
0397nobodyさん2008/02/15(金) 17:32:39ID:???
勉強になるなぁ。

俺はセッションに入れる派。
0398nobodyさん2008/02/15(金) 17:47:48ID:???
hiddenみればわかると思うけど
yahooなどの超有名サイトほど、ログイン処理など
きわめて便利でないとこ以外はセッションを使ってない
0399nobodyさん2008/02/15(金) 17:48:37ID:???
OpenPNEもログイン処理以外はセッションを使ってない
0400nobodyさん2008/02/15(金) 18:01:38ID:???
単純に考えてもセッションが途中で切断されたとき
データの引継ぎが途中で止まる
hidddenにデータがはいってないので
最初からページ移動のやりなおし






0401nobodyさん2008/02/15(金) 18:13:03ID:???
なるほど。それは納得。

hiddenは値をいくらでも改竄できるからどうも・・・。
それすると挙動がおかしくなるサイトもあるし。
まぁ、それはそこの実装者が悪いだけなんだけど。

今のところセッションの方が生産性高いから、セッションで実装しちゃうな〜
0402nobodyさん2008/02/15(金) 18:16:11ID:???
セキュリティ的にいえば毎回ＤＢと照らし合わせが基本
セッション多様は開発者が楽するためのもので
サイト運営者、利用者にとってセキュリティリスクでしかない
0403nobodyさん2008/02/15(金) 18:24:00ID:???
セキュリティ的にどうのこうのって、さっきから一切具体的な話がないんだよね。
0404nobodyさん2008/02/15(金) 18:49:34ID:I3wnpJfD
Not Found
0405nobodyさん2008/02/15(金) 19:08:46ID:???
毎回DBと何を照らし合わせるんだ？
リクエストされたパラメータが改竄されていないかどうかをチェックするということか？

そんなことをするならばセッションにデータを格納したほうが効率が良いだろう。
悪意あるリクエストによってサーバセッションの中身を改竄するのは、
パラメータを書き換えるよりは困難だ。

他人のセッションを乗っ取ったり、MITM攻撃などでの手法はまた違う議論。

セッションを使おうが、パラメタを使おうが、適切な処理を行わなければ
どちらもセキュリティリスクになる。

どちらの方法も処理次第では脆弱になりうる。
逆に言えば、どちらの方法でも適切な処理を行えば十分安全になる。
ここでいう*十分安全*という定義はサービスの内容によって異なる。
0406nobodyさん2008/02/15(金) 19:10:27ID:???
ページ移動にセッション使ってるやつて、どういうコード書いてるのさ
具体的に指摘してやるからコード晒してくれ
0407nobodyさん2008/02/15(金) 19:39:23ID:???
外のサイトからデータ引っ張ってきて確認画面等でページ移動するときはセッションで引き回してる
他はログインID引き回すぐらいかな
ちなみにCAKEのデフォルト通りにIPでも（自動で）チェックしてるからドコモの人はさよならな俺のサイト
0408nobodyさん2008/02/15(金) 20:04:49ID:???
>>406
具体的に？
いや、だから、あるアクションでセッションにデータ入れて関連する他のアクションで参照するっていう、ほんとそのまんま。
コード書くまでもない。
0409nobodyさん2008/02/15(金) 21:21:34ID:Q8bQtypz
セキュリティという面ならhiddenで取り回すよりもセッションの方がまだマシだと思うけど違うの？
hiddenだと改ざんされてしまうし・・・。
けど、何でもかんでもセッションにってのは確かに気持ち悪いわな。
0410nobodyさん2008/02/15(金) 21:43:28ID:???
hiddenの場合って「入力画面 -> 確認画面 -> DB登録」って時に、確認画面からhiddenでDB登録に渡すでしょ
確認画面の時にバリデートして、DB登録直前にまたバリデートって面倒じゃない？(hidden値改竄の可能性があるから)

セッションだったら確認画面でセットしたデータがDB登録の時になって変わることがないからいいんだけど
0411nobodyさん2008/02/15(金) 22:23:55ID:???
hiddenにもセッション変数にも問題はあるから、扱う情報によってケースバイケースでは？
個人的には、セッション変数を使うのが良いと思うが、
セッション変数は手軽に増やせるので、コードの質を低下させるのを気をつけたい。
例えば、index.phpですべてのリクエストを受けて、
$_SESSION['action']で場合分けみたいなコードを編集したことがあるけど、
$_SESSION['action']はsession_start()さえしておけば、コードのどこでも変更できるので、
きちんと規約を決めておかないと副作用で死ぬ。
フレームワークに期待するのは、そういう規約の部分なんだけど。
0412nobodyさん2008/02/15(金) 22:28:43ID:???
ちなみにセッションが小技的に有用だと思ったのは、
Javascriptからしか参照されないJSONで、
ユーザ固有のデータを出すときに、いちいちPOSTしなくて良い点。
遷移の上で孤立したアクションでユーザ固有のデータを使える。
0413nobodyさん2008/02/15(金) 22:30:54ID:???
セッションのサイズが大きくなったらどうするんだ？
たとえばセッションのサイズが1MBになったら、
データ読み込みに時間がかかるだろ？
↑
反論

ページ移動するたびに、
1MBものデータをhiddenでクライアントに転送し
それをまたサーバーに送信するようなことをしたら
もっとパフォーマンス悪いだろ？
0414nobodyさん2008/02/15(金) 22:56:12ID:???
>>413
いや、そもそも、設計を見直せ、って話だろ、それ。
0415nobodyさん2008/02/15(金) 23:02:40ID:???
「設計を見直せ」というだけなら簡単
0416nobodyさん2008/02/15(金) 23:05:36ID:???
データをセッションに保存しないとしたらどこに保存するんだろうな？
セッション＝ファイルなわけで、ファイルに保存するか、
データベースに保存するかの違いしかないんだが・・・
0417nobodyさん2008/02/16(土) 00:07:09ID:???
386です。

セッションIDのみでデータベースから読み出して処理するのがベストなのですか。
勉強になりました。ありがとうございます！
0418nobodyさん2008/02/16(土) 00:20:43ID:???
セッションをデータベースに保存すれば
それで終わりだなｗ
0419nobodyさん2008/02/16(土) 02:31:23ID:???
なんだかんだ言って、幅広い意見が聞けて有益なスレだ
0420nobodyさん2008/02/16(土) 02:42:17ID:???
>>410が言ってるような、複数のリクエスト(アクション)を一つの論理単位としてその中でのデータの受け渡しをどうするかって話だろ
なんかDBのデータ(ユーザデータとか)を全部セッションにぶちこむかどうかの議論と勘違いしてるのがいるな

途中経過のデータをセッションに入れるのはセキュリティ的によくないとか、セッションにはログインIDしか入れちゃいかんとか、その理由を述べろよ
0421nobodyさん2008/02/16(土) 03:28:41ID:???
無駄である。以上。
0422nobodyさん2008/02/16(土) 03:33:13ID:???
その無駄とは、理由を聞いても答えられないから
無駄という意味か？ｗ
0423nobodyさん2008/02/16(土) 08:57:57ID:???
セッションは必要最小限で使えというのは
大手を含め全員一致の答え、
ページ移動でもhidden内容を何でもかんでもセッションに詰め込むのは問題

・セッション変数の重複関係でバグ
・ページ移動中に他のサイト見に行ったりしたとき
・セッション変数が開放されないことによるバグ
・セッション切断による、変数の維持ができないバグ


0424nobodyさん2008/02/16(土) 09:28:46ID:???
> ・セッション変数の重複関係でバグ
バグが問題なだけ

>・ページ移動中に他のサイト見に行ったりしたとき
ページ移動中に他のサイト見に行ったりしたとき、
hiddenだと入力途中のデータ消えるバグ

> ・セッション変数が開放されないことによるバグ
バグが問題なだけ

> ・セッション切断による、変数の維持ができないバグ
セッション切断したのに、変数が維持されるバグ
0425nobodyさん2008/02/16(土) 14:40:12ID:???
hiddenと比較するとセッションの方がバグ管理するポイントが多い
しかも致命的バグを生む可能性が高いのはセッション
0426nobodyさん2008/02/16(土) 14:50:25ID:???
>>423
>セッションは必要最小限で使えというのは大手を含め全員一致の答え
なんで大手代表できるの？全員って？
ここの書き込み見るだけでもセッションでやってる人いるよね。
まぁせまい範囲だけど、知り合いとか知ってる会社とか、セッションで実装してるとこも多々ありますよ。

>セッション変数の重複・セッション変数が開放されない
これはバグじゃなくて、これに対処するコードを書かなきゃいけないっていうセッションのデメリット。
逆にhiddenのデメリットはhtmlに埋め込まなきゃいけない、改竄に対処するコードを書かなきゃいけないってことかな。

>・セッション切断による、変数の維持ができないバグ
セッション切断されたら変数の維持がどうのこうのじゃなく処理自体継続できない。ログアウトされるから。
ログインがないシステムだったらhiddenのほうがこの問題にはちゃんと対応できるね。
0427nobodyさん2008/02/16(土) 14:53:57ID:???
楽したい低脳プログラマが使いたがってるだけだろ＜セッション
0428nobodyさん2008/02/16(土) 15:01:08ID:???
>>427
楽して何が悪いｗ
0429nobodyさん2008/02/16(土) 15:05:46ID:???
1.2betaにはfind('count')とfind('list')を使ったとき、
afterFindが呼び出されないバグがあるな。
behaviorで文字コード変更してたら文字化けした。
だれか報告してきてくれ。

find('count')はafterFindを呼び出す例を思いつかないが
呼び出したほうがいいのだろう？ たぶん。
0430nobodyさん2008/02/16(土) 15:07:33ID:w7he1Bjb
>>427
いかに楽できるのかを考えるのが(効率の)いいプログラマなんだと思うんだが
どっちのメリット・デメリットも理解した上でデメリットに対応し、自分の楽なほうを選んでるんだからいい
何の説得力も説得材料もないそんなことしか言えないお前のほうがよっぽど低脳だ
0431nobodyさん2008/02/16(土) 15:28:00ID:???
>>430
じゃあなんでyahooはページ移動にセッション使ってないんだよ
効率悪いプログラマの集団かｗ
yahooにはＰＨＰ創始者もエンジニアとしているんだけどなｗ

0432nobodyさん2008/02/16(土) 15:35:42ID:???
低脳にそんなに反応するのか
やっぱり能力の低さがコンプレックスになってる奴は違う
0433nobodyさん2008/02/16(土) 15:37:13ID:???
ヤホーじゃなくてお前の意見を言えｗ
0434nobodyさん2008/02/16(土) 15:38:25ID:???
>>431
yahooにとってはhiddenのメリットのほうが大きかったってことだろ
ちなみにデメリットの対処を考えると実はセッションの方が楽ではない

>yahooはページ移動にセッション使ってない・ＰＨＰ創始者もエンジニアとしている
これは何の技術的理由にもならないことが分からんのか？
っていうか継続データのやり取りにセッション使ってないって保証はどこにあんの？
0435nobodyさん2008/02/16(土) 15:40:00ID:???
ここにいる低脳プログラマのやってることは
納品さえすれば、後のことは関係ないみたいなのばっか
セキュリティ０
0436nobodyさん2008/02/16(土) 15:41:09ID:???
>>431
楽天の会員登録ではセッション使っているようだが？
https://www.rakuten.co.jp/myrakuten/login.html
0437nobodyさん2008/02/16(土) 15:43:44ID:???
やり方としてはどちらもありだし、
セキュリティもどちらが上というわけじゃないのに、

たまたまYAHOOがやっていたということを根拠にするのやめてくれない？ｗ
ちゃんと自分の意見を言おうね。
0438nobodyさん2008/02/16(土) 15:45:31ID:???
---------------------------------------

　やり方としてはどちらもありだし、
　セキュリティもどちらが上というわけじゃないのに

---------------------------------------

　同意
0439nobodyさん2008/02/16(土) 15:53:34ID:???
セキュリティもどちらが上というわけじゃないのに?
セッションよりもhiddenの方が安全に決まってるだろうがｗ
セキュリティで危険なのってセッション絡みが多い
hiddenで危険なのって聞かないというか
セッションだろうが最初の画面はhiddenで飛ばすし
0440nobodyさん2008/02/16(土) 15:56:02ID:???
hiddenで毎画面チェックして
最終画面でも総チェックした方が
セキュリティは上

セッションは書き換えられたらおしまい
0441nobodyさん2008/02/16(土) 15:58:36ID:???
rails様がセッションでもhiddenでもなくクッキーに書き出してるんだから
おまえらもクッキーにしようぜ
0442nobodyさん2008/02/16(土) 16:03:51ID:???
hiddenじゃセッションの代わりにはならないよ？
他のページ行ってもどってきたらデータを引き継げない。
0443nobodyさん2008/02/16(土) 16:04:24ID:w7he1Bjb
>>439
>セッションよりもhiddenの方が安全に決まってるだろうがｗ
うん、だからhiddenの方が安全な理由を教えてよ
「hidden セッション」とかで検索するとhiddenのほうが否定的なんだけど

>>440
>セッションは書き換えられたらおしまい
これはセッションを(少しでも)利用してるシステム全部に言えること
継続データをhiddenにするかセッションにするかとは全く論点が違う
0444nobodyさん2008/02/16(土) 16:05:52ID:???
>>439
お前の言うことと「ipa.go.jp」のどちらを信じるか言うまでも無いｗ

hiddenは危険（セッション変数を利用しよう）
http://www.ipa.go.jp/security/awareness/vendor/programming/a01_05.html
0445nobodyさん2008/02/16(土) 16:33:40ID:???
そんな糞みたいなサイトじゃなくてひろみちゅ先生の話聞こうぜ

安全なWebアプリ開発の鉄則 2004
http://www.soi.wide.ad.jp/class/20040031/slides/09/
2006.4.4「CSRF」と「Session Fixation」の諸問題について
http://www.ipa.go.jp/security/vuln/event/documents/20060228_3.pdf
安全なWebアプリ開発の鉄則 2006
http://www.nic.ad.jp/ja/materials/iw/2006/proceedings/T21.pdf
0446nobodyさん2008/02/16(土) 17:02:33ID:???
ここまで馬鹿と利口が鮮やかに色分けされているスレも珍しいな。
0447nobodyさん2008/02/16(土) 17:03:41ID:???
>>446
どちらが馬鹿か指摘してよ。そうすればあんたが馬鹿かかどうかわかるからｗ
0448nobodyさん2008/02/16(土) 17:06:26ID:???
>>447
「とりあえずお前はバカのボックスに入ってくれ」とさ
■ このスレッドは過去ログ倉庫に格納されています