>>296
コントローラに関する再利用性の高いメソッドはコンポーネント
モデルに関する再利用性の高いメソッドはビヘイビア

再利用性が高いロジックじゃないとダメ
そのロジックがコントローラ側かモデル側かどっちに属するかを間違えるとダメ

>>300
再利用性が無いなら
１０万stepsでもコントローラにベタ書きするしかないよ

>>299
コンポーネントはコントローラとモデルの仲介役じゃねーよｗｗｗ

>>299みたいに再利用性の低いものまでコンポーネントはダメだろな

ビヘイビヤって1.2からのやつだよね？

>>296
コンポーネントにすべてモデルを操作するカスタムメソッドを記述してます

これダメだろ？再利用性の高さとか無視してるやん

1.1てバリデーションのyaml化できないんでしょ
それだけでもオワッテルｗ

都道府県データとか
男性・女性・オカマとか
こういうセレクトに必要な初期データはどこへ入れるの？

>>307
spyc重くね？

>>308
とりあえずモデル作ってfind('list')呼んでセレクトボックスへ流す。
都道府県データなんてほぼ100%変更出ないからデータの中身は定数でもいいし
郵便番号検索とか使うアテがあるならデータベース使う。
中で何やってるかは置いといて、ともかくモデルから呼べる事が大事。

>>309
モデルのメソッドの中に都道府県データをいれて
呼び出してもＯＫ？
もしくはＤＢからひっぱる、それ以外に方法はわからない

データ量の多い定数なら、別ファイルにして
呼び出すときにモデル経由でincludeして呼び出すのがいいのかな

>>298
ケーキを使っている以上ケーキ様の言うことは絶対です。

コンポーネントにいろいろ書くとどれだけテストが大変になるか。

>>308
> 男性・女性・オカマとか
これじゃ足りないな。

現在の肉体的性別 男・女
生まれたときの肉体的性別 男・女

現在の精神的性別 男・女
生まれたときの精神的性別 男・女

好きな性別 男・女・両方・肉体が男・肉体が女

まだ足りないかもな！

>>313
再利用できないものは
コントローラーにいろいろ書くしかない
ケーク様が何も用意してくれてないから

>>298の言ってる事はともかく
>>313はAuthComponentのソース見た事あるのかな

うんこちんちん

こんなに、解釈によって作り方が変わって来ちゃうなら、フレームワークの「良い意味での縛り」のメリットが無いね。
それぞれが間違いとも正解とも言えないから余計めんどくさい。
もっと縛りがキツければ良いのに。

>>319
バカがルールを勘違いしてるだけｗｗｗ

俺が作っているやつでは、「自動入力フィールド」をビヘイビアでやっている。
ユーザーが入力した情報を加工したものを別フィールドに自動的に保存する。
データベースのセオリーからいえば計算で求められる物なのでビューやトリガーを使うところだが、
パフォーマンスを重視＆汎用性を高めるためにこうしている。

あとどこかでぐぐって見つけた画像を保存するビヘイビア。

あるテーブルに保存したら、自動的にほかのテーブルにメタ情報を保存するビヘイビア
つまりトリガーの代わりだね。

文字コード変換ビヘイビア

仕様が変わって使っていないが、一つのフィールドに複数の値を入れられる配列型フィールドを作るビヘイビア。
（一対多のテーブルを作れというなよ？そんなJOINが発生する重い処理を作りたくないこともあるんだ。
SQL99 で標準規格化されたしね。）それの応用でオブジェクト（シリアライズ）型

それともうひとつあるのだが、これはちょっとアイデア賞物だと思うので自分のブログで書きたいｗ

結構いろいろ使っているなｗ 総論としてデータベースの機能を拡張したいときに使っている。

>>322
日本語でおｋ
あいかわらず文章下手糞やなｗ
単純なことをわかりにくい表現するの好きやな
前スレから全く変わってねーな

>>322
結局cakeライブラリのモデルで実装されてる機能を少し拡張したいときに
ビヘイビアにいれてるんでしょ？

>>322
ユーザーが入力した情報を加工したものを別フィールドに自動的に保存する。

この自動的て具体的にどういう意味？

>>322
ユーザーが入力した情報を加工したものを別フィールドに自動的に保存する。

これは前スレで自作ヘルパーでやってなかったか？
パフォーマンスを重視＆汎用性を高めるというのに具体的内容が欲しい

>>322
一つのフィールドに複数の値を入れられる配列型フィールド

ＳＮＳのような大規模サイトでもこれ使う機会なんて滅多にないんだが、何作ってんの？

>>322
配列型フィールドて
mysqlでも検索や集計はできるの？

>>322
配列型フィールドを使わない人にとっては
激しく必要のないビヘイビアじゃね？

>>322
それともうひとつあるのだが、これはちょっとアイデア賞物だと思うので自分のブログで書きたいｗ

恒例自慢きたこれｗ

なんだこの過剰反応ぶりｗ

みるからに同一人物のようだが、
ただの使用例に必死すぎだろｗ

○○○を使わない人にとっては
激しく必要のない○○○じゃね？

なんにでも当てはまるなｗ
無理やり反論しようとして滑ってる。

>>331
>>332
同一人物乙

確かに同一人物だが、それが何か？

>>333
cakephpとは外れたこと書くな

CakePHPで開発するアプリを設計する際にUMLで書いてる人いる？
シーケンス図やクラス図なんかどんな風に記述してるかとか見せてもらえると
参考になります。

>>336
UMLを使うと従来の方法より効率が落ちる時もある。
なぜなら、従来なら手書きで適当に書いてきた図をUMLでどうやって書けばいいのか調べなければならないから。
書き方が全部頭の中に入った後でなら従来よりスムーズに開発ができるようになるかもしれない
が、しかし、それまでは相当の苦労が必要ｗ
オブジェクト指向開発とUMLとはまた別の話でUMLはオブジェクト指向開発の道具にすぎない

>>336
UML？時間の無駄だろ。そんなん書いてたら
工数オーバーするしで誰も喜ぶもんおらんで

Ｃ＃やＪＡＶＡならわかるけどＰＨＰでＵＭＬて
そんなクラスが複雑じゃないやん

そういう問題じゃねーだろｗ

そりゃぐぐったことが無いという人もいるだろう。
だがそれは個人の話であって統計的な意味は無い。

検索結果のほうがまだ意味があるな

PHP UML の検索結果 約 957,000 件中 1 - 10 件目 (0.03 秒)
Java UML の検索結果 約 593,000 件中 1 - 10 件目 (0.04 秒)
C# UML の検索結果 約 404,000 件中 1 - 10 件目 (0.04 秒)

Cakephpと関係ない話すんなやボケどもが

>>340
そういう問題だろｗ

俺はJavaをメインでやってるけどＵＭＬは
複雑になってくるクラス間の関連性の構造の手助けとしてＵＭＬを活用することが多い
だから>>339のいってるように複雑なクラスで無ければ必ずしもＵＭＬが必要とは思わない

ユースケースは必ず書くけど、シーケンスみたいな実装よりの奴は
実装者が未熟な場合か、処理が複雑なときだけかな。
クラスダイアグラムはモデル限定でこれもテーブル構成が複雑なときだけ。

ユースケースは文書に起こして仕様書にするので必須。

PHPのクラスを自動生成してくれる奴なかったっけ?
あれでCakeのモデルを自動的に管理してくれると楽かも...楽じゃないかw

UMLのクラス図ってようするに継承関係と関数定義（実装コード無し）を
書いているだけでしかないからなぁ。

それならコードで書いてコードからクラス図を自動生成したほうが楽。

Javaだとクラスが複雑になってしまうんだよね。
正確にはEJBを使った場合だが、同じものを作るにしても
無意味に複雑になりすぎる。
あれじゃあ、UMLが必要になるのもわかる。

ちょwww おまえら設計書も書かずに開発しちゃってるのかよ、涙がでるな。
それだから「できました」とかいいながらテストしたらバグ出まくりのプログラムなんか量産しちゃうんだよwwww

UMLじゃなくてもいいが、実装前に詳細なロジックを書き起こしてからコードつくるのは常識だろ。
時間がかかる、めんどくさい、頭の中にもう仕様書書いてあるから、という奴に限ってたいした技術力じゃないんだよな。
設計書ってのはコーディング作業が楽になるだけでなく、チーム関係者との意識共有や、リリース後しばらくたってメンテが必要になった時に効果がでるもんだぜ。
プロとして仕事でやってるならば当たり前だと思ってるが、ここにはプロはいないのか？