元スレ【PHP】フレームワーク CakePHP　6ホール目【v1.2】

php覧 / PC版 /

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

751 = :

当たり前なのか？
商用では何が使われてるんだよ

752 = :

CakePHP使ってますと公言してもメリットがないから
使ってるサイトが少なそうに見えている、とも考えられる

あと1.2で大分ましになったけど、同じフルスタックとはいえ
導入するメリットがSymphonyに対して見えにくかったというのもある。
簡単だ！みたいな点だけ強調されすぎた。なんかそういうのはもういい。
その点では1.2になって本当に良くなった。敷居は上がったかもしれんが

753 = :

>>752
同意。俺、商用サイトしか作らないけどここ2年近くは全てcakephpを元に作ってる。
わざわざcakephpで作ってますとは書かないね。

754 = :

制作事例を公表するというのは、セキュリティ的には、システムの脆弱性をさらすようなものだから、
よっぽど強固な作りになっていない限り、制作事例は公表しないというのが面倒が無くて良い気がする。

オレは、仕事でCakePHPを組込んでいるよ。どれか教えないけどね

755 = :

>>753
そらパクってるからな笑

758 = :

要するにキャンセルがあるからダメなの？

だったら自前でダイアログ(っぽいもの)を吐き出す必要があるのでは？

760 = :

何言ってんの？
ちゃんと他人が理解できるよう質問しろバカ

764 = :

勝手にキャッシュされんだろ
スレチ

765 :

最近cakephpを使って開発を始めたんですが、少し気になる事があったので質問させてください。
データのCSVの保存とかは、ドキュメントを見た感じモデルに書くべきって書いてあったからいいんですが、
データの計算や、加工等などはどこでやるべきなのでしょうか？
MVCの概念からいくとモデルになるのでしょうが、Cakeの場合モデルはDB操作や、
データの保存等に使用のみ（？）と書いてあったのでどこに書くべきか迷っています。

すみません、ご教授お願いします。

766 = :

コントローラに書くとそのコントローラからしか呼び出せない(正確にはにくい)
モデルだと、そのモデルを使うコントローラすべてから使える
データに密接な加工はモデルに書くべきでしょ

http://www.sooey.com/journal/2008/03/26/717/

ていうかすごく根本的なことだと思うが・・・

767 = 765 :

>>766
ありがとうございます。
URL先の記事非常に参考になりました。

770 = :

>>768
Auth+ACL

>>769
俺もそれでよく躓く
そういう仕様らしくてどうしようもないのかも。
どうしてもやりたい時はビヘイビアでやるけどこれも一筋縄ではいかない
他の方の回答を期待したい

771 = :

>>769
http://cakephp.seesaa.net/article/97445048.html

772 = :

モデルの意味を勘違いしている人が多いよね。
データに関わるものであれば、モデルでビジネスロジックを書いてもいいのに。

774 = :

>>771

769ではないけど
その機能はしってるけど、そうじゃなくて以下のような時にどう実装すればいいんだろ

モデルがUserとPostの2つあって
Post BelongsTo Userのとき

User.ipにはip2longしたIPアドレスを持っていて
UserモデルにはafterFindでIPアドレスをlong2ipで復元するように書いてある
なのでUser->find等したときは意識せずとも勝手に変換されたIPを取得できる。

この時に
Postモデルから芋づるでUserも引っ張ると、UserのafterFindを通らない。

778 = :

>>771のエントリを読むと、芋づる方じゃなくて芋づられる方のデータを対象に出来るって書いてあるね
ためしてないが

780 = :

769書いた後12時間爆睡してしまいました。

アソシエーションがA HABTM B なんで>>774とは微妙に違うんですが、
今やってみると…両方とも思いっきりafterFind通っていました。なんでだろう。
ちょっと気持ち悪いけどとりあえず解決下っぽいです。
ありがとうございました。

781 = :

夜型か地球の裏側住まい乙

784 = :

>>783
つhttp://book.cakephp.org/ja/view/683/beforeSave
「このコールバックは、データが保存される前にそのデータを加工する場合、特に便利です」

785 = :

>>773
>>773
>>773
>>773

786 = :

>>784
さんくす。モデルって関連づけとバリデーションくらいしか触ってなかた。

788 = :

CakePHPというか、アメリカ圏というべきかな。では
ドメインモデルの設計が主流みたいなんだよね。
それに対して日本はトランザクションスクリプトが多い感じ。
（低レベル日本じゃこの考え方自体があまり知られていない感じもするけどｗ）

なので、ドメインモデルとして使えばCakePHPは複雑なこともかなりやれるけど、
トランザクションスクリプトでやろうとすると、なんでこんなことがやりにくいの？ってなってしまう。

データを加工して表示するのはビュー。処理はモデル。
コントローラはモデルに処理を依頼して、ビューにデータを渡すだけ。
こういう設計にするのが一番じゃないかな。

789 = :

>>766のURLはテンプレにいれてもいいんじゃないかな
この概念を知らないでCakeいじってた頃は今思うと悲惨だった

790 = :

afterFindの件、今やると確かに通ってる
バージョンアップで変わったのか勘違いかどっちかです。
時間できたらテストしてみます

おさーがせしました

791 = :

>>790
たしか、バージョンアップで変わったが正解だと思う。

俺も昔、それ関係でソースを呼んでいたのだが、
ひもづるで呼んだときは通らなくて、
まあ、SQLの仕組み上JOINして持ってくるだろうから
難しい話だと思ったのでそいういう仕様かなぁと思っていた。

たぶん今俺が使って実稼動しているシステム。
新しいCakeでは動かないだろうな・・・
ちゃんとテストしているからすぐ修正できるとは思うが。

793 = :

>>789
もう入ってるんですけど>>3

794 = :

変わりに言っておこう。

穴があったら入りたい。

795 = :

お前らレベル高いな

ココも勉強になるわ

799 = :

>>766みたいな方法でも良いと思うが、
メゾット毎に役割を決めた方がメンテナンス性が上がるような気がする。

800 = :

おーテンプレはいってましたか
えらいすんまへんでした