【PHP】フレームワーク CakePHP　3ホール目【本命】

【PHP】フレームワー� ..

178:nobodyさん
08/03/18 13:03:45
初期値の設定は、前回入力値の設定と同じことなんだから
コントローラで設定すべきだよな。

ビューはただ表示するだけ。

179:nobodyさん
08/03/18 15:07:02
>>178
根拠の無い理由は自分の心の中でしまっとけな

180:nobodyさん
08/03/18 15:09:23
>>177
167に書いたよ、この美しいコードに反論あるんか？

181:nobodyさん
08/03/18 15:11:30
>>173
こんなコード書く奴がこのスレにいるとは
CakePHPの住人レベルて・・・

182:nobodyさん
08/03/18 15:13:24
明らかにＰＨＰ初心者がCakePHPから始めましたみたいなのが多いな
>>173を見て確信した

183:nobodyさん
08/03/18 15:20:33
ああ。ガチだな。

184:nobodyさん
08/03/18 15:59:35
最近10分以内に似たようなレスが連続で湧くな

185:nobodyさん
08/03/18 16:06:00
じゃあアンケートとります。

フォームの初期値はどこで設定すべきでしょう。

1.コントローラ
2.ビュー
3.モデル
4.モデルに初期値情報が有り、それをコントローラが取得してビューに渡す

俺は4。面倒だとか、フォームによって初期値が違う場合は1

186:nobodyさん
08/03/18 16:45:53
>>185
俺はビューかな。

187:nobodyさん
08/03/18 16:51:14
>>185
俺もビュー
管理するのが楽
コントローラーに書くとみにくくなる
ビューだと全くみにくくない、それどころか見通しがよくなる

188:nobodyさん
08/03/18 16:53:16
>>185
モデルをこれ以上見にくくするのはよくないよ
バリデータ
アソシエーション
バリデータ関数
これだけでもずいぶん見にくいのに

189:nobodyさん
08/03/18 16:54:16
コードの見渡しがよくなって
変更が楽な場所がベスト

190:nobodyさん
08/03/18 16:55:18
>>185
初心者の多いここでアンケートとっても意味が無いけどなｗ

191:nobodyさん
08/03/18 17:06:20
常識的に考えればビューだけど
ここは初心者が多いからね

192:nobodyさん
08/03/18 18:10:04
>>188
お前、まさか、それだけしかないんじゃないだろうな・・・
モデルは設定ファイルじゃないぞ。

ビジネスロジックを書く所がモデルだぞ。

193:nobodyさん
08/03/18 18:11:06
ビューは基本的に表示のみを行う場所。
初期値をビューで設定するのは変。

194:173
08/03/18 19:04:45
確かにてきとーに書いた部分はあるが
何でダメなの？因みにcakeは１週間ぐらいしかやってない
あとコントローラに初期値は
ロジックとviewの分離等から考えると微妙だが
めんどくさかったんだそこはごめんｗ

195:nobodyさん
08/03/18 19:29:58 5PAxNly0
なんでここって初心者しかいないの？

196:nobodyさん
08/03/18 19:38:40
なんでここって猿みたいに同じ事しか書けない人が多いの？

197:nobodyさん
08/03/18 20:28:19
>>193
smartyだってテンプレート側で初期値いれらるようになってる
おまえの頭が変

198:nobodyさん
08/03/18 21:23:10
>>193

携帯用サイト作るとわかると思うけどあんまりガンガン表示する内容まで
コントローラーで固めない方がいいよ。

携帯用サイト用のコントローラーまで作る羽目になるから。

199:nobodyさん
08/03/18 22:59:49
セッションって

$_SESSION['']['']　を直接使った方が早い感じがすんだけど、みんなどうしてます？

やっぱり $this->Session->read を使った方がいいんですかね。

200:nobodyさん
08/03/18 23:48:37
>>197
> smartyだってテンプレート側で初期値いれらるようになってる
入れられるようになっているからって、入れるべきということにはならないだろ？
モデルやコントローラ側で初期値入れられるようになっているんだしさ。

> 携帯用サイト用のコントローラーまで作る羽目になるから。
その理屈がよくわからん。初期値の話をしているのに
なんでもコントローラでやると拡大解釈してしてないか？

それにビューに書く場合、携帯用サイトとPC用サイトで分けるもんだから、
ビューに初期値を書いたら、コードが重複するじゃん。
だからビューだけはありえない。そう思わないか？

ちなみに、おれは初期値はモデルに書くもんだと思っているが。

201:nobodyさん
08/03/19 01:30:55
>>199
オブジェクトで呼んだ方がオーバーライドもできるし
後から制御するのが楽

202:nobodyさん
08/03/19 01:36:20
柔軟な制御をするためにデータはオブジェクト経由で呼ぶべき
オブジェクトで呼ぶことに意味がある
それは、オブジェクトにはいってるデータを
外から制御できるからだ

203:nobodyさん
08/03/19 07:53:45
>>201
>>202

cakephp やってて

「意味あるのかな・・・」と思ってましたけど、やっぱり意味があったんですね。

勉強になります。ありがとうございます。

204:nobodyさん
08/03/19 12:54:14
例えばCakePHPでブログシステムを作るとして、
ユーザ（usersテーブル）、投稿（commentsテーブル）が一対多の
関係にある時、あるviewで、
　ユーザ1
　　コメント1-1
　　コメント1-2
　　コメント1-3
　ユーザ2
　　コメント2-1
　　コメント2-2
　　コメント2-3
　　　・
　　　・

という表示をさせたいのですが、view、controllerをどう書いてよいか悩んでいます。
modelで、hasManyリレーションを貼るところ迄は合っていますか？

どこか、参考になるページがあれば教えて下さい。

205:nobodyさん
08/03/19 19:47:56
UserモデルにはhasManyプロパティを作ってcommentsを持っていることを示す。
CommentモデルにはbelongsToプロパティを作って、usersに依存していることを示す。

コントローラのアクションでUserモデルからデータを引っ張ってくる
アソシエーションによりCommentもくっついてくる。

コントローラのアクションで、引っ張ってきたデータを
ビューに詰め替える。

ビューは渡されたデータをぐるぐるして表示する。

206:nobodyさん
08/03/19 21:42:10
表示するユーザ数+1のクエリが発行されるからアクセス数の多い中規模～大規模なサービスでは使えない。
この辺言及する人が少ないのはcakeユーザのレベルが低いからだろうか。

207:nobodyさん
08/03/19 22:11:32
> 表示するユーザ数+1のクエリが発行されるから
何を言っているんだ？

自分のレベルが低いと告白しているのか？

208:nobodyさん
08/03/19 22:21:01
>>206
だって、表示するユーザ数+1のクエリが発行されないから。
誰も指摘しないのは当たり前。

209:nobodyさん
08/03/19 23:03:06 XOo5uLlV
>>205
返信ありがとうございます。

> コントローラのアクションでUserモデルからデータを引っ張ってくる
> アソシエーションによりCommentもくっついてくる。

なるほど。
きちんとリレーションを設定すれば、コントローラ側ではUserモデル
からデータを引っ張るだけで、芋づる式にcommentsを取れるんですね。

> ビューは渡されたデータをぐるぐるして表示する。

今、$usersをforeachで回してる状態なんですが、これを$usersと
$commentsの二重ループにすればオッケーですかね。
ちょっとやってみます。

>>206
論点がずれてませんか？

そもそも、具体的なアクセス数、H/Wの規模を示さないと意味のない
指摘じゃないでしょうか。
この方法だと中規模以上に向かないから、この方法を使うといいよ、
と言うのならまだ分かるのですが。

210:nobodyさん
08/03/19 23:13:10
>>207
>>208
お前らのcakeはこの時どういったクエリが発行されんの？

select ... from users ... (id 1,3,5のユーザがヒットする)
select ... from comments where user_id in (1) ...
select ... from comments where user_id in (3) ...
select ... from comments where user_id in (5) ...

211:nobodyさん
08/03/19 23:28:29
URLﾘﾝｸ(72.14.235.104)

そして、この findAll() で実行された SQL は以下の通り。

SELECT `Job`.`id`, `Job`.`com_id`, `Job`.`name`
FROM `jobs` AS `Job` LEFT JOIN `coms` AS `Com` ON `Job`.`com_id` = `Com`.`id`
WHERE 1 = 1 ORDER BY `Job`.`id` ASC LIMIT 10;

212:nobodyさん
08/03/19 23:42:19
belongsToじゃなくてhasManyのこと言ってるんだけど。
参照の方向が違う。

213:nobodyさん
08/03/20 00:12:41
といわれてもなぁ、

hasmanyとかconditionsにどういうSQLで
JOINするかをSQLの断片で書いているしなぁ。
JOINしているとわかりそうなものだがなぁ。

214:nobodyさん
08/03/20 00:28:36
子はJOINできないじゃん。
結局「表示するユーザ数+1のクエリが発行される」が間違ってることは示せないんでしょ。
実際やってみてクエリログ見ればすぐ分かるはずなんだが。

215:nobodyさん
08/03/20 00:37:04
>>210
素人乙！
観点がずれてるよＰＨＰの基礎からやりなおしてね

216:nobodyさん
08/03/20 00:40:19
１回のクエリで全てが補えることに超したことはない
その代わり複雑なＳＱＬ文を書かないといけないから
CakePHPの負荷よりも生産性というスタイルに合わないがな
ループの中でクエリをぐるぐる発行しまくると負荷が高くなる

217:nobodyさん
08/03/20 00:43:11
>>215
結局こういうのが出てくるのか・・・
ほんとバカばっかだなー

それじゃ論点がどうずれてるか説明もらってもいい？
210での発言にphpの基礎は全く関係ないから、それのほうが論点ずれてると思うのだが。
んで、実際お前のcakeではこの処理でどういうクエリが発行されんの？

218:nobodyさん
08/03/20 00:47:43
>>209
よほどのことがない限り
ループの中にループは入れない方がいいよ
負荷がかかるからね。

219:nobodyさん
08/03/20 00:52:19
CakePHPのおかげで
とてつもなく負荷の高いシステムがたくさん世に出そうだな
こりゃサーバー会社が儲かるな
sakuraインターネット株でも買うか！

220:nobodyさん
08/03/20 05:31:17
1.2のpaginate機能はつかえねーな
柔軟な制御ができん、
ページリンクに検索項目のパラメーター付加できない、というか
できるけど、面倒なことしないとダメくさい
ソート項目のパラメータは標準で付加できるようだが

221:209
08/03/20 10:56:59 mwRuCB98
>>218

私の技術力だと、二重ループ以外に実現する方法が思いつかないのですが、
他によい方法があったら教えてもらえますか？

ユーザ毎のコメントを表示する機能はパスするにしても、
同様にmasManyリレーションのテーブルを親子両方とも表示したい
機会はあると思うので。

負荷という意味では、masManyの定義でlimit=>10とする事で大量の子を
取得しないように、というのは心がけています。

222:nobodyさん
08/03/20 11:48:27
>>219
もっと負荷の高いsymfonyもありますぜｗ

223:nobodyさん
08/03/20 12:36:12
というか、プライマリーキーで
データを取得することが
負荷が高いと思っているのかな？

JOINの方がよっぽど負荷高いですぜ。

224:nobodyさん
08/03/20 12:40:34
DB周りじゃないだろ多分

225:nobodyさん
08/03/20 12:58:50
>>210
> お前らのcakeはこの時どういったクエリが発行されんの？

こういうクエリが発行されますがなにか？

select ... from users ... (id 1,3,5のユーザがヒットする)
select ... from comments where user_id in (1, 3, 5 ) ...

226:nobodyさん
08/03/20 13:35:31
CakePHPのどんどん負荷をかけて生産性を上げなさいというスタイルが
自分の性格に合わない気がしてきた

227:nobodyさん
08/03/20 13:39:58
まだ、例のアンチが常駐しているのかｗ

CakePHPはメモリも食わないし、負荷も高くない。
生産性は高い。

228:nobodyさん
08/03/20 13:40:43
アンケート

1.ページ送りの絞り込み条件パラメータをセッションで持たせている
2.ページ送りの絞り込み条件パラメータをURLの後ろに繋げてる(CakePHP1.1 paginate)
3.ページ送りの絞り込み条件パラメータをURLの後ろに繋げてる(CakePHP1.2 pagination)

229:nobodyさん
08/03/20 13:45:28
>>228

4. 基本は3と同じだが、場合によってpagination等をオーバーライドして独自の条件を追加している。

230:nobodyさん
08/03/20 13:45:45
>>227
矛盾してるな。それらは反比例の関係にあるからな

231:nobodyさん
08/03/20 13:45:54
>>226
たしかに、
●自分の用途に合わせて、全てのコードとHTMLを一から作成したシステム
●作り込み部分は最小限にして、大半のコードはcakePHP任せにしたシステム
を比べると、負荷は、一から作成したシステムの方が、余分なものがない分、
軽くできるかもね。

まあそこはトレードオフの部分だから、自分に向いてないと思ったら、
cakePHP以外のやり方を模索すればいいと思うよ。

232:nobodyさん
08/03/20 13:47:58
>>230
よくわからんが、いまどき生産性の悪いほうを
選びたいのか？

233:nobodyさん
08/03/20 13:49:21
負荷が高いシステムを作っているところは
どこでもフレームワークを使っている。

234:nobodyさん
08/03/20 13:50:32
>>229

View側で
$paginator->prev()
$paginator->next()

の第２引数に絞り込み条件を配列で入れてやら無いと
URLの後ろにパラメーターが付加されてなくない？

URLﾘﾝｸ(localhost)
みたいなかんじ

235:nobodyさん
08/03/20 13:55:14
>>234
いまソースが手元に無くて忘れたが、CakePHP1.2でかなり改善された。
そういえば、そういうパラメータを”コントローラ”側で追加していたきもする。
コントローラーのpagination変数だったっけ？
pagination[モデル名]だっけ？
まあわすれた。

236:nobodyさん
08/03/20 13:55:53
>>233
どちらかと言うと、「負荷が高いシステム」と言うより、
「大規模なシステム」はフレームワークを使ってるという感じじゃない？

そうしないと、コーディングや保守が大変だもんなあ。

237:nobodyさん
08/03/20 14:03:35
結局は、昔からある速度重視でアセンブラ（生PHP）で書くか、
生産性重視で高級言語（フレームワーク）で書くかの話でしかないな

238:nobodyさん
08/03/20 14:07:42
小規模フレームワークはＣＩが一番だと思うんだよね
CakePHPは小規模フレームワークのクセにsymfonyと同レベルくらい負荷かかりすぎ

239:nobodyさん
08/03/20 14:12:16
>>238
宿題。

それをデータで示してください。

つーか、何をもって小規模といっているのかわからん。

240:nobodyさん
08/03/20 14:15:07
機能が少ないほうが早い。機能と速度どっちをとるかだ。

241:nobodyさん
08/03/20 14:15:17
>>239
10万stepまで　小規模
データは「CakePHP CodeIgniter ベンチマーク」でググれ

242:nobodyさん
08/03/20 14:18:04
>>239
URLﾘﾝｸ(www.tsujita.jp)

243:nobodyさん
08/03/20 14:20:54
だめだな。CodeIgniter は小規模でしか使えない。
一番重要なモデルが貧弱すぎる。中規模以上ならCakePHPだな。
URLﾘﾝｸ(blogs.atanaka.biz)

・フレームワークにありがちな、あまり使わない機能が削がれている
・フレームワークにありがちな、よく使う機能もけっこう削がれている。
・だから、ステップ数が他のPHPフレームワークと比べて格段に少ない。
・だから、実行速度が速い。（ベンチマークはこちら）
・フレームワーク自体が複雑なことをしようとしていないので、潜在バグの深刻さも小さい。（たぶん）
・マニュアルがかなり読みやすく、取っつきやすい。
・cakePHPには名前のインパクトには負ける。
・ZendFramework には格式の高さで負ける。
・MVCというよりは、VCだ。モデルはあくまでもおまけ的。
・PHPがそもそもテンプレート的なんだからテンプレートエンジンいらない、と考えているふしあり。（だから速い、と）
・でも、簡単な変数置き換えの簡易テンプレートはデフォルトでついてるし、Smartyとの連携もできる。

244:nobodyさん
08/03/20 14:22:14
流行らないフレームワーク。そっちで盛り上げてくださいｗ

[PHP][フレームワーク]CodeIgniterスレ
ｽﾚﾘﾝｸ(php板)

245:nobodyさん
08/03/20 14:25:59
>>243
モデルはCIベースでオレオレ的に拡張した方がいい。
CakePHPの既存モデルにしっくり来ないから
まずコードが凄く見難い状態になる
結局バリデートにYAML使ったりと拡張しないいけない

246:nobodyさん
08/03/20 14:27:28
小規模 CodeIgniter
中規模 CakePHP
大規模 Symfony

これでいいじゃん

247:nobodyさん
08/03/20 14:29:19
小規模　CI
中規模 CI
大規模　ここまできたらCIでいいや

248:nobodyさん
08/03/20 14:31:12
ＣＩのサクサク感を味わうと他のＦＷは使えない

249:nobodyさん
08/03/20 14:36:26
>>225
それバージョンいくつ？

250:nobodyさん
08/03/20 14:36:52
viewの先頭でoptions()を使って追加文字列をセットしておけば、prev()やsort()等で追加の指定する必要なくなる
$paginator->options(array('url'=>'hogehoge'))

controllerでpaginate(モデル)した後のoptionsにセットしてもurlに展開される
$this->params['paging'][モデル]['options']['hogeoge_key']='hogeoge_value'
*この方法は裏技的な気がするけど、、、

251:nobodyさん
08/03/20 14:39:31
>>249
1.2ですが？

252:nobodyさん
08/03/20 14:40:57
痛いCI厨は自分のスレを盛り上げてこいよｗ
わざわざCakePHPスレを盛り上げて乙

253:nobodyさん
08/03/20 14:46:46
経験から言うと、どんなものでも「軽い！」という触れ込みでデビューしたものは、
最初は機能が少なくて、バージョンがあがるにつれて機能が追加され最終的には重くなるんだよな。
で、ほかと同等の機能を備えたときには、ほかと同等の重さになっている。

254:nobodyさん
08/03/20 15:00:55
CIスレですが、今週の日曜以降、書き込みがありません。
使ってる方、どうぞ書き込んで下さい。

ｽﾚﾘﾝｸ(php板)l50

255:nobodyさん
08/03/20 15:11:51
akelosスレなんてもっと（ｒｙ

256:nobodyさん
08/03/20 15:33:39
>>251
hasManyアソシエーションでlimitを指定しないと確かに225のクエリになる。
ソース読んだらそのためのif文があった。これは知らなかった。サンクス

limit指定しないのが普通なのか・・・あと、なんでそういう実装にしてるんだろう。
limitでUserの件数絞るとしてもwhere user_id (1,3,5)はできると思うのだが。

257:nobodyさん
08/03/20 15:35:10
間違えた。
> limitでUserの件数絞るとしても
limitでCommentの件数絞るとしても

258:nobodyさん
08/03/20 15:42:11
>>256
>>257
面倒ならカスタムsqlでやれば早いじゃん

259:nobodyさん
08/03/20 15:42:19
んー、Commentに対するlimitがある場合はそう実装するしかないのか。
バカじゃん俺。この振る舞いについてのドキュメントはどっかにあったのかな。
連投スマソ。

260:nobodyさん
08/03/21 01:06:38
Cakeとは関係ないんですが、複数のモデルの処理(全部更新)を1個のトランザクションにするときってどう書いたらいいですか?
コントローラーにこんな感じで書こうと思うのですがどうでしょうか。

start transaction

$resultA = $modelA ->method();

if($resultA == 'error')
{
rollback
return;
}

$resultB = $modelB ->method();

if($resultB == 'error')
{
rollback
return;
}

$resultC = $modelC ->method();

if($resultC == 'error')
{
rollback
return;
}

commit

261:nobodyさん
08/03/21 04:01:36
>>260
スレ違いだと思うんだけど・・・

262:nobodyさん
08/03/21 11:15:08
confirmぺルパー作成完了

263:nobodyさん
08/03/21 11:28:48
ぺルパーについてkwsk

264:nobodyさん
08/03/21 22:38:30
バリデートのyaml化作業開始

265:nobodyさん
08/03/22 02:17:57 rTbTxKR5
コンポーネントの中でモデルって使えるよね、$this->モデル名とかで。
コントローラにはあまり詳細な処理は書きたくない（つまり、大まかな流れだけ）ので、
具体的な処理はコンポーネントをこさえて、そちらで処理したいんだけど考え方あってるかな？
たとえば、会員登録処理をするアプリを例にすると、UserRegisterComponentみたいなのを作って
identify()やregister()、update()といったモデルを扱う処理を記述して、
コントローラーからはフォームの値の受け取りとコンポーネントをコネコネ使うこと、結果によって
ビューを表示しわけるようなイメージです。
ソース書いて晒した方が早い？

266:nobodyさん
08/03/22 03:46:35
>>265
> コントローラにはあまり詳細な処理は書きたくない
> 具体的な処理はコンポーネントをこさえて、そちらで処理したい

大事なのはこれらの明確な理由が何なのかってことだと思う。
その会員登録処理がシステムの他の部分からも必要になるならコンポーネントにした方がいいと思うよ。
もしくは他のアプリでも(ほぼ)そのまま使用できるなら。
あとはコントローラとモデル(DAO層)を分離することでテスタビリティを向上させたいとかかなぁ
例えばテストの時はモックコンポーネント使うようにすればデータベースがなくてもコントローラのテストができる。

267:265
08/03/22 05:08:43 rTbTxKR5
>>266
なるほど。コンポーネントで会員登録処理と思いついた理由は指摘のとおり他のアプリで
いつも同様のことを実装してるのでコンポーネント化してしまおうというのが一番の理由。
それにコントローラ内に細かい条件分岐や処理を書き始めるとものすごくコードが肥大して
メンテナンスがし難いし、もし今後会員登録のフローを同アプリケーションの別箇所でも使い
たいって仕様変更があっても対応しやすいかと。

でも、「会員登録（管理）コンポーネント」なんて作っちゃうとモデルやDBテーブルの構造が
かなり固定化＆依存してしまうのがいやだなだ、と…（AuthComponentみたいにね）
それならばpluginにしちゃえば？って考えることもあるけど、pluginってあんまり使われてないし。
うーむ。

268:nobodyさん
08/03/22 10:11:22
>>267
そんな恐ろしいほどにコードが肥大する。かつそれら共通利用する機会が多いなら
コンポーネント化しちゃいなよ

269:nobodyさん
08/03/22 10:19:47
>>267
DBテーブルの構造がかなり固定化＆依存

これ内容が会員登録だったらテーブル構造に依存しちゃうのやばいだろ？
会員認証なら固定依存しても、それほど問題ないけど
コンポーネントてそもそもDBテーブルの構造がかなり固定化＆依存してしまうものなんだね

270:nobodyさん
08/03/22 10:52:32
>>267
コンポーネント設計のポイントは、Plug-and-Playを可能にすることであり、独立性を高めることにある
重要となる設計要素は、インターフェースであり、注目すべきは設計要素間の依存関係だと思う
内部実装に依存しない形でコラボレーションをモデル化できるインターフェースが重要じゃないかな

コンポーネント化するということは、結局クラスをグループ化することだからね
クラス間の関連（集合-部分、汎化-特化）と依存関係を意識して設計しないと
物理的にはコンポーネント化したが、論理的にはひとつのシステム全体
ひとつの再利用単位として使わざるを得ないという状況が現れるから
この点で、依存関係の設計はかなり重要

271:nobodyさん
08/03/22 11:26:27
>>266
モックコンポーネント

あまり聞かない、組み合わせだけどｗ
モックとコンポーネント入れ替えするものじゃないの？

272:nobodyさん
08/03/22 11:49:52
モックンがどうかしたって？

273:nobodyさん
08/03/22 19:56:20 rTbTxKR5
ちなみにCakePHPのプラグインを配布してるサイトをご存知ですか？
「配布できる」と書いてあるくせに、プラグイン配布サイトって見たことないやと思って。
「会員登録プラグイン」とかあるといいのになー

会員登録コンポーネントの件、結局ユーザーテーブルを分けて（users:ログインIDとパスワードだけ、user_profiles:その他のプロフィール項目）
コンポーネントで固定化するのはusersテーブルを主にして、user_profilesの方はアプリケーション毎に
自由に定義できるような仕様でコンポーネントを書いてみようかと思っています。

274:nobodyさん
08/03/22 20:52:09
>>271
そういうこと。テストの時はモックを使うようにする。
「コンポーネントのモック」って意味でモックコンポーネントって言った。

275:nobodyさん
08/03/22 21:01:00
>>273
会員登録プラグイン

何度も使うような処理でも無いし面倒な処理でもないからなあ

個人的には確認画面やらページ送りやら何度も使う場面のあるプラグインもしくは
コンポーネントが欲しい

276:nobodyさん
08/03/23 01:31:09
バリデートのyaml化作業完了
yamlの空白に少しはまった

277:nobodyさん
08/03/23 02:03:00
>>276
おつかれっす

278:nobodyさん
08/03/23 12:24:28
findのような感じで、IDを指定してDBデータの更新を
ファンクションはありますか？イメージとしてはこんな感じで。
$this->Post->hogehoge($id, 'Address'->'Hokkaido');

Model classのファンクションを一通り眺めてみたのですが、
それらしきファンクションを見つける事ができませんでした。

URLﾘﾝｸ(api.cakephp.org)

279:nobodyさん
08/03/23 13:03:51
>>278
ファンクションて何ですか？素人は書き込まないで下さい

280:278
08/03/23 13:46:28 9wMqWTzf
>>279
先に挙げたURLで、「Public Member Functions」と記述されていたので、
ファンクションと書かせてもらいました。

methodと言えばいいですか？
既存のものでいうと、findAllやsaveなどの事です。

ご存じでしたらお教え下さい。

281:nobodyさん
08/03/23 14:00:59
>>280
こんなとこで聞くよりも自分でソース見た方が早くね？

282:nobodyさん
08/03/23 21:00:13 xiSCrZA7
>>275
会員登録プラグイン、完成したら俺にくれ

283:nobodyさん
08/03/23 22:20:17
>>282
いらねー。たぶん需要ない
会員登録なんてすぐ作れるやんｗｗｗ

284:nobodyさん
08/03/23 23:07:41
>>278
カラム単位の更新でいいなら、saveField。

$this->Post->id = $id;
$this->Post->saveField('Address', 'Hokkaido');

285:nobodyさん
08/03/23 23:25:30
いらなきゃ使わなきゃいいじゃん。
小さい車輪だろうが再開発をしなくて済むなら助かる。

286:nobodyさん
08/03/24 00:14:26
再開発する機会が少ない。激しく無駄
そうじゃなければ、すでに作ってる人たくさんいるよ

287:nobodyさん
08/03/24 00:19:02
ほんとにいらなければ何もコメントしないので、たぶん荒らし。
スルー推奨。

しばらく前、本やWebを参考にRoRを使っていたが、cakePHPの方が
使いやすい。
ひょっとしたら、RoRでActiveRecordとかに若干慣れたので、
馴染みやすかっただけかもしんないけど。

288:nobodyさん
08/03/24 00:22:17 gAnd/HKb
Cakeのプラグインって、なにか有名なのってあったっけ
なんのためにプラ銀機能なんて実装されてんの？

289:nobodyさん
08/03/24 03:29:33
都道府県データどこにいれてる？

290:nobodyさん
08/03/24 03:37:25
コントローラ全体じゃなくてメソッド単位でヘルパー、コンポーネント呼び出すにはどうすればいい？
会員登録ページのメソッドにアクセスしてるにもかかわらず
コントローラでPaginationコンポーネントを定義していれば
ページ処理の関わるクラスがnewされるんでしょ

291:nobodyさん
08/03/24 13:06:37
ヘルパーは細かく考えずにコントローラ単位で呼び出すのがCake流
コンポーネントやモデルはヘルパーに比べればメソッド単位で呼び出しやすいけど
こっちも深く考えずにコントローラ単位で呼び出すんだ
多分

292:nobodyさん
08/03/24 13:16:08
例えばググレカスアクションでほげヘルパーを呼び出す場合

function gugurekasu() {
　　 App::import('Helper', 'Hoge');
　　 $ajax = new HogeHelper();
}

293:nobodyさん
08/03/24 20:55:32
まあ、そんなに特定のアクションでだけ
ヘルパーとか呼び出したいのなら、
そういうコンポーネントを作ればいいんじゃないのかな？

コンストラクタあたりで、url見てごにゃごちゃすれば出来るでしょう？

294:nobodyさん
08/03/25 00:59:47
>>292
ネーミングが中途半端だな
HogeHelperだけ普通やん

295:nobodyさん
08/03/25 01:51:15
>>294
むしろ$ajaxに突っ込んで欲しかったな

296:nobodyさん
08/03/25 10:30:40 Qe2AafnS
モデルってあんまりごちゃごちゃ書きたくないよな、dbdesigner2cakeとか使ってるとメンテナンスの面からとく。
だからといってコントローラにごちゃごちゃとロジックを書き並べたくないので
コンポーネントにすべてモデルを操作するカスタムメソッドを記述してます。

これって俺だけ？

297:nobodyさん
08/03/25 10:37:30
だからコントローラにいろいろ書くのは
まずいケーキだってケーキ様が言っている。

URLﾘﾝｸ(cakephp.org)

298:nobodyさん
08/03/25 10:46:51
>>297
ケーキがどうのこうのいおうが
自分の見やすい書き方が一番

たとえば１万step以下のコードなら
全部コントローラに書いた方がいい、みたいなね！

299:nobodyさん
08/03/25 10:55:58 Qe2AafnS
>>297　
3ページ目？　こんなにモデルに書くもんかね…
俺だったらｃとｍの間のコンポーネントをずっしり書くな。別のプロジェクトにも使いまわしできるし。
コントローラだとほぼ、使いまわせないしな。

300:nobodyさん
08/03/25 11:02:26
1万ステップコントローラにべた書きとかすごいね

301:nobodyさん
08/03/25 11:05:24
>>296
コントローラに関する再利用性の高いメソッドはコンポーネント
モデルに関する再利用性の高いメソッドはビヘイビア

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

302:nobodyさん
08/03/25 11:07:56
>>300
再利用性が無いなら
１０万stepsでもコントローラにベタ書きするしかないよ

303:nobodyさん
08/03/25 11:08:52
>>299
コンポーネントはコントローラとモデルの仲介役じゃねーよｗｗｗ

304:nobodyさん
08/03/25 11:12:12
>>299みたいに再利用性の低いものまでコンポーネントはダメだろな

305:nobodyさん
08/03/25 11:13:20 Qe2AafnS
ビヘイビヤって1.2からのやつだよね？

306:nobodyさん
08/03/25 11:14:25
>>296
コンポーネントにすべてモデルを操作するカスタムメソッドを記述してます

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

307:nobodyさん
08/03/25 11:17:23
1.1てバリデーションのyaml化できないんでしょ
それだけでもオワッテルｗ

308:nobodyさん
08/03/25 11:22:06
都道府県データとか
男性・女性・オカマとか
こういうセレクトに必要な初期データはどこへ入れるの？

309:nobodyさん
08/03/25 11:38:31
>>307
spyc重くね？

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

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

311:nobodyさん
08/03/25 11:44:21
データ量の多い定数なら、別ファイルにして
呼び出すときにモデル経由でincludeして呼び出すのがいいのかな

312:nobodyさん
08/03/25 12:29:56
>>309
> spyc重くね？
書くのはYAMLでもキャッシュとしてPHPのシリアライズデータに
変換してそれを読み込むから重くない。

313:nobodyさん
08/03/25 12:34:26
>>298
ケーキを使っている以上ケーキ様の言うことは絶対です。

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

314:nobodyさん
08/03/25 12:38:32
>>308
> 男性・女性・オカマとか
これじゃ足りないな。

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

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

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

まだ足りないかもな！

315:nobodyさん
08/03/25 13:04:07
>>313
再利用できないものは
コントローラーにいろいろ書くしかない
ケーク様が何も用意してくれてないから

316:nobodyさん
08/03/25 13:06:05
>>298の言ってる事はともかく
>>313はAuthComponentのソース見た事あるのかな

317:nobodyさん
08/03/25 16:31:35
コンストラクタでぐにょぐにょしたいときは
コンストラクタ内で先に
parent::__construct();
を呼ばないとダメだよ
なぜ？て
それは>>318が答えてくれるはず

318:nobodyさん
08/03/25 17:10:42
うんこちんちん

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

320:nobodyさん
08/03/25 18:12:31
>>319
バカがルールを勘違いしてるだけｗｗｗ

321:nobodyさん
08/03/25 18:24:02 Qe2AafnS
ビヘイビアのうまい使い分けがわかんないー

Emailコンポーネントと連携して"emailable=1"を判別してメールするビヘイビアだとか、
ソフトデリート(＝削除フラグ=1を削除）を実装したビヘイビアとかのサンプルは目にした
んだけど、もっと実践に役立つ使い道ってどんな風なの？？

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

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

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

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

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

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

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

323:nobodyさん
08/03/26 02:10:48
>>322
日本語でおｋ
あいかわらず文章下手糞やなｗ
単純なことをわかりにくい表現するの好きやな
前スレから全く変わってねーな

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

325:nobodyさん
08/03/26 02:29:03
>>322
ユーザーが入力した情報を加工したものを別フィールドに自動的に保存する。

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

326:nobodyさん
08/03/26 02:34:57
>>322
ユーザーが入力した情報を加工したものを別フィールドに自動的に保存する。

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

327:nobodyさん
08/03/26 02:40:36
>>322
一つのフィールドに複数の値を入れられる配列型フィールド

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

328:nobodyさん
08/03/26 03:04:09
>>322
配列型フィールドて
mysqlでも検索や集計はできるの？

329:nobodyさん
08/03/26 03:06:22
>>322
配列型フィールドを使わない人にとっては
激しく必要のないビヘイビアじゃね？

330:nobodyさん
08/03/26 03:12:41
>>322
それともうひとつあるのだが、これはちょっとアイデア賞物だと思うので自分のブログで書きたいｗ

恒例自慢きたこれｗ

331:nobodyさん
08/03/26 03:36:11

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

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

332:nobodyさん
08/03/26 03:41:59
○○○を使わない人にとっては
激しく必要のない○○○じゃね？

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

333:nobodyさん
08/03/26 03:47:41
>>331
>>332
同一人物乙

334:nobodyさん
08/03/26 03:51:47
確かに同一人物だが、それが何か？

335:nobodyさん
08/03/26 04:15:24
>>333
cakephpとは外れたこと書くな

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

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

338:nobodyさん
08/03/26 04:59:22
>>336
UML？時間の無駄だろ。そんなん書いてたら
工数オーバーするしで誰も喜ぶもんおらんで

339:nobodyさん
08/03/26 05:04:03
Ｃ＃やＪＡＶＡならわかるけどＰＨＰでＵＭＬて
そんなクラスが複雑じゃないやん

340:nobodyさん
08/03/26 05:24:25
そういう問題じゃねーだろｗ

341:nobodyさん
08/03/26 10:28:27
>>339
確かにphpでＵＭＬてぐぐったけどあまり無いな

342:nobodyさん
08/03/26 10:50:05
そりゃぐぐったことが無いという人もいるだろう。
だがそれは個人の話であって統計的な意味は無い。

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

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

343:nobodyさん
08/03/26 11:29:28
Cakephpと関係ない話すんなやボケどもが

344:nobodyさん
08/03/26 11:31:39
なんでCakePHPにＵＭＬの話が出るのかわからんｗ

345:nobodyさん
08/03/26 11:37:41
>>340
そういう問題だろｗ

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

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

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

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

348:nobodyさん
08/03/26 12:24:40
UMLのクラス図ってようするに継承関係と関数定義（実装コード無し）を
書いているだけでしかないからなぁ。

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

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

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

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

351:nobodyさん
08/03/26 14:32:19
楽譜の読めないミュージシャンもいるしな。

352:nobodyさん
08/03/26 15:25:48
>>350
実装前に詳細なロジックを書き起こしてからコードつくるのは常識だろ

それお前だけの常識乙ｗ
CakePHPのような小規模案件に無理があるぞお前ｗ

353:nobodyさん
08/03/26 15:29:27
>>350
どこの大手で働いてんだよCakePHPさわってる分際でｗ

354:nobodyさん
08/03/26 15:34:17
>>350
CakePHPでいくらも稼げてねーくせにｗ

355:nobodyさん
08/03/26 15:37:50
短納期で回転させるのがCakePHPのメリットなのに
わざわざＵＭＬとか工数伸びるだけやんけ
そんなんで、ほんまに黒字になってんのかｗ

356:nobodyさん
08/03/26 15:41:14
>>350
スレ違いながら言わせてもらうと・・

実際、開発しながら見えてくる事って多いよね。
キチンと設計や仕様固めが出来ないまま、見切りスタートを切ってしまうことも多々。
問題は、その仕様の追加、変更に対応出来るように設計する事だよ。

357:nobodyさん
08/03/26 16:12:51
そうなんだーUMLって書かないんだ。
俺は書き方すら知らないけど。

作る前に一応メモに何をどうするかを書き出して、その通りに作ってくね。
あまりに自分の頭の中だけで作ると変数とか何を使ったかわからなくなったり。

イラレで仕様書とか作るのが激しくめんどい。
よって手書きで自分はやってます。

358:nobodyさん
08/03/26 16:15:44
>ここにはプロはいないのか？
w

359:nobodyさん
08/03/26 17:32:25
え…設計フェーズ飛ばしていきなりコーディングに入るの？ギャグだろ？
最低限、要求定義書とユースケースとビジネスロジック(=モデル)の関係図とそれを基にしたスキーマ設計位は必要じゃねーの
打ち合わせ段階で作りまくるじゃん、そんなの
どやってクライアントのイチャモンに対応してるの？

>>357
イラレで仕様書とか正気？

360:nobodyさん
08/03/26 17:56:28
パワポが激しくめんどくさい。
よって俺もexcel＆イラレだな。

361:nobodyさん
08/03/26 17:58:19
まあ、コーディング前の設計は
概要みたいなもんだからね。

たとえば関数をすべてコーディング前に列挙できるかといったらまず不可能

プロのプログラマはコードで設計するんだよ。
鉛筆で図を書くか、キーボードでコードで書くかの違い。

362:nobodyさん
08/03/26 18:01:13
プロはソースにたくさんコメントを残す。

363:nobodyさん
08/03/26 19:04:34
×プロはソースにたくさんコメントを残す。
○プロはソースに意味のあるコメントを残す。

364:nobodyさん
08/03/26 20:37:18
>>359
もっとプログラマと交流深めた方がいいよ

365:nobodyさん
08/03/26 20:39:13
>>359
どんだけ狭い世界観なんだよ

366:nobodyさん
08/03/26 21:07:55
10分以内（　´,_ゝ`）

367:nobodyさん
08/03/26 21:55:41
>>364
この人、確実に嫌われてるだろうな、プログラマに。

368:336
08/03/27 00:00:03 d9lPRB8S
>>336です
意外と盛り上がっててびっくり…

369:nobodyさん
08/03/27 01:42:38
>>359

イラレで仕様書は普通。

370:336
08/03/27 02:53:28 d9lPRB8S
>>369
マジかよ。それなんてイラレ？

371:nobodyさん
08/03/27 11:48:14
たとえばフォームにある省略可能な数値型の項目に
値を省略して（空文字で）データベースに保存した場合空文字でINSERTされる。

このときのどう保存されるか動作はデータベース依存であり
MySQLは0になり、PostgreSQLはエラーになる。

URLﾘﾝｸ(trac.cakephp.org)
チケットが出ていたみたいだが、修正無しでクローズ？

これ直る見込みないんかいな。確かに空文字とNULLは違うものだが
「データベースの省略可能な数値フィールド」ってのは
数値とNULLしか入れられないんだよね。

どうせNULLが入ったフィールドをModelから読み込むと
空文字になるんだし（あってるよね？）
NULLに変換して保存したほうが実用的だと思うんだけどなぁ。

データベース間の違いも吸収したほうがいいし。

beforeSaveあたりで書き換えるか・・・

372:nobodyさん
08/03/27 15:25:42
>>371
それはCakePHPに限ったことでは無いから死んでこい

373:nobodyさん
08/03/27 15:27:34
>>371
そんなどうでもいい作業するくらいなら
コンビニでバイトするよ

374:nobodyさん
08/03/27 17:50:07
CakePHPのアソシエーションでBelongsToやhasOneを渡り歩いて
広範囲のテーブルから値を持ってくるにはどうすればいいんでしょうか

SQLならLEFTJOINを繋げて行けば済むのですが
単純にrecursiveを増やしていくとクエリの量が異常に増えて困っています

375:nobodyさん
08/03/27 19:31:16
最近低レベルの煽りしか返さない奴がいるなウザイ。
どうせ同一人物だろうからトリップつけてくれ。削除すっからさ。

376:nobodyさん
08/03/27 19:48:23
>>375
低レベルの質問しかないから仕方ないこと

377:nobodyさん
08/03/27 19:51:40
>>374
リファレンスみろよ
こんなとこで聞くなカス

378:nobodyさん
08/03/27 20:14:15
>>376-377 だからトリップつけろってｗ

379:nobodyさん
08/03/27 21:54:01
>>377
アソシエーションが直接繋がっている関係なら資料は山ほどあるのですが
例えば4テーブル先まで繋がっているデータを手繰り寄せてくる場合、デバッグ情報を見ると
一旦findで取得してきた配列をforeachで回して一つ一つまたfindを使っているように見えます
結果、データ自体は取ってこれるもののSQLの発行数が異常な量になってしまいとても使う気になれません

SQLの発行を抑えつつもアソシエーションを柔軟に広げるためには、自前でqueryを使うしかないのでしょうか？

次ページ