>>300
俺はいつもindexに書き込み処理をつけるね。
そういう場合。

MVCについてイマイチ自分が理解してないのもあって、てっきりcrudの4機能は別のメソッドに書かなきゃならないものなのかと思っていましたが、そうすれば全部解決なんですよね。
実は今回やってるものが非常に特殊なケースで、IE6対応も切り捨てられないため、ajaxでやろうとして困っているところでした。

＞MVCについてイマイチ自分が理解してないのもあって、
馬鹿

cakephp形式のURL配列で
hoge/fuga/hoge2
まで指定したい場合はどうしたらいいんでしょう？
controller=>hoge,action=>fuga,のあと、hoge2にあたる部分の指定の仕方がどうにも見当たりません。

すいません、自己解決しました。
最後のhoge2に当たるところで数字を使っていたのがどうもよくなかったみたいで、文字列に変えたところ、actionを指定した後にカンマを打ってそのまま書くだけでうまく行きました。
でもコントローラからstrvalしてビューに渡してもなぜかビューではint扱いされるんですね。

スレチ

>>317
どうせ設定ミスだからまず最初にローカルで動作確認してから
同じ設定をvalueserverに張り付けた方がいい
レンタルサーバーでいきなりcron動かすのは問題点特定しにくいから鬼門

環境構築面倒くさがってレンタル鯖でテストするやつもいるからなあ
今ならビルトインサーバで一発だし今回みたいなケースもxampp使えばすぐなのに

3.0のドキュメントって英語版もまだだいぶ不親切だな
saveallがやってた動きがどうにも再現できん、難しいこと全然やってないのになあ

cakephp1で動いてるサイトあるんだけど、機能を追加したい。
3ヶ月かけて作ったサイトなんだけど
2でリニューアルすべき？
みんなならどうする？

1と2や3は修正点多いから、コスト安くするなら1のままで機能追加したいかな、
CakePHP以外にもPHPのバージョンを5.x系の最新にする手間もあるし

バージョン上げるなら、3がRC版がリリースされたので3に上げたい、
だけど上げるとしても機能追加とバージョンアップ作業は別々にした方が安心、
同時だとCakePHP、PHPのバージョンアップ、機能追加とやる事多過ぎで混乱すると思う

>>323
ありがとうございます！

独り事だけど、setFlashってめちゃくちゃ便利だな。
セッション使うから嫌って変数を作ってたんだが、setFlashだけで良いことに気づいた。
elementも指定できるから、処理が成功/失敗のHTMLを出力することも出来るし、ビューに無駄な箇所が減る。

これから新規で開発しようと思うんだけど
3使うのってまだ早いですかね？

公式ドキュメントも日本語訳まだ整備されてないですよね

cakephp使ったことないけど3系になったら
使ってみたいわ

ドキュメントが日本語になってないことより、ドキュメントに書いてないことを調べる術が少ないのが困るな
ドキュメントに書いてないことが多いのはいつものことなんだけども

>>333
自分ならusersに会員タイプ判断用のtypeフィールド追加して、その値によって動的にcontainさせる
hasoneアソシエーション自体は三つとも設定しておく

あと実際の運用でこの程度のフィールド数なら
タイプごとにテーブル分けなくてもいい気がするけど
省略してるフィールドが多いならこのテーブル構成でいいと思う

3を触ってみてるんだけど、複数のフォームから送信されたデータをエンティティに変換する方法がよくわからない
newEntities()で一発変換できるって書いてたんだが、それだとformのcreateには何渡せばいいんだ？まずnewEntityしたのを渡してからpostが飛んできたらpatchEntitiesって感じにすると返り値が変な配列になるし

>>334
やっぱりContainする方法がベストですかね。ありがとうございます。

あと、省略しているフィールドは多いですね。
1テーブル20ぐらいありますし、後に増える可能性もあります。
パスワード再設定用のテーブルや退会した理由をを保存するテーブルなど
ユーザー+共通テーブルがいくつかあるため、分ける形を採用しました。

$this->Item->find('all', array(
'conditions' => array(
'AAncestor.id' => 1,
'BAncestor.id' => 1
)
));

上記のようにすると、SQLエラーが出ます。
=> Error: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'AAncestor.id' in 'where clause'

当面の解決策として
$this->Item->find('all', array(
'conditions' => array(
'AParent.a_ancestor_id' => 1,
'BParent.b_ancestor_id' => 1
)
));
とし、それぞれ祖先ではなく、親のforeign_keyにて対応しています。

例えばconditionsに [AAncestor.name, BAncestor.name] を使いたい場合
一度それぞれでfindを走らせIDを取得することで一応は解決しましたが、
あまりスマートに見えませんし、更に離れたアソシエーションだと難儀しそうです。

上手いやり方もしくは根本的な考え方の違いがあるのでしょうか？
シンプルそうなのに検索しても解決策がみあたらず、困っています。

よろしくおねがいします！ 👀

>>340
>ルーティングとコントローラー/モデルを切り分けて考えた方がいい

という一文でハッとしました。
確かにURLはルーティング次第でどうとでもなりますよね。
1つのコントローラーでまとめるのではなく、
シンプルに目的に応じたコントローラー・アクションを作ります。

ありがとうございました！

ビッ○カメラ札幌店の副店長の佐藤伸弦が暴行事件が起きていた

佐藤伸弦　佐藤伸弦　佐藤伸弦　佐藤伸弦　佐藤伸弦

佐藤伸弦　佐藤伸弦　佐藤伸弦　佐藤伸弦　佐藤伸弦

佐藤伸弦　佐藤伸弦　佐藤伸弦　佐藤伸弦　佐藤伸弦

佐藤伸弦　佐藤伸弦　佐藤伸弦　佐藤伸弦　佐藤伸弦

佐藤伸弦　佐藤伸弦　佐藤伸弦　佐藤伸弦　佐藤伸弦

>>332
元のソースを追っかける癖をつけとくと捗るぞ
マニュアルでピンと来なくてもソース見れば、なーんだってことは良くある

>>343
権限

>>345
2系まではわりと適当だけど3系になってからPSR準拠になってるし少しずつ従っていった方がいいよ
俺はmysqlとかjsとの連携を考えるてずっと変数はスネークケースでやってきたけどそろそろ潮時かもしれん
phpcsでたくさん例外作るのも面倒だしね
でもインデントがスペース四つなのは未だに納得できない

>>346
1つのサイト作るのに色んな命名規則使うから悩みますよね。
CSSやJavascriptでもそれぞれ必要とされる規則は違うし。

ただ、変数にキャメルバックはどうも違和感があるんですよね・・・
キャメルバックにする分、文字数が減って見やすくなるとは思うんですが。
あと、インデントはスペース4つではなく2つにしてます。さすがに4つは長いかと。

という事を考えると、色々とCakeの規則から逸れてしまいますね・・。

自分の経験で規則から逸らしたくなるようじゃ
経験が足りないってことなんだよｗ

経験があるからこそ規約に疑問を持つのだろう
PSR通りにコーディングするのは今日からプログラム始めた素人にもできる

みんなが疑問持ちながら好き勝手に書くと良くないから
グループ開発の指針としてコーディング規約があるにすぎない

経験が「ない」からじゃなくて「足りない」からね

大勢が使う何かの規約を責任持って作ったことがあれば
それからわざわざ逸そうなんて思わないってこと