私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】フレームワーク CakePHP 3ホール目【本命】
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 : ○
レスフィルター : (試験中)
痛いCI厨は自分のスレを盛り上げてこいよｗ
わざわざCakePHPスレを盛り上げて乙
わざわざCakePHPスレを盛り上げて乙
経験から言うと、どんなものでも「軽い！」という触れ込みでデビューしたものは、
最初は機能が少なくて、バージョンがあがるにつれて機能が追加され最終的には重くなるんだよな。
で、ほかと同等の機能を備えたときには、ほかと同等の重さになっている。
最初は機能が少なくて、バージョンがあがるにつれて機能が追加され最終的には重くなるんだよな。
で、ほかと同等の機能を備えたときには、ほかと同等の重さになっている。
>>251
hasManyアソシエーションでlimitを指定しないと確かに225のクエリになる。
ソース読んだらそのためのif文があった。これは知らなかった。サンクス
limit指定しないのが普通なのか・・・あと、なんでそういう実装にしてるんだろう。
limitでUserの件数絞るとしてもwhere user_id (1,3,5)はできると思うのだが。
hasManyアソシエーションでlimitを指定しないと確かに225のクエリになる。
ソース読んだらそのためのif文があった。これは知らなかった。サンクス
limit指定しないのが普通なのか・・・あと、なんでそういう実装にしてるんだろう。
limitでUserの件数絞るとしてもwhere user_id (1,3,5)はできると思うのだが。
間違えた。
> limitでUserの件数絞るとしても
limitでCommentの件数絞るとしても
> limitでUserの件数絞るとしても
limitでCommentの件数絞るとしても
んー、Commentに対するlimitがある場合はそう実装するしかないのか。
バカじゃん俺。この振る舞いについてのドキュメントはどっかにあったのかな。
連投スマソ。
バカじゃん俺。この振る舞いについてのドキュメントはどっかにあったのかな。
連投スマソ。
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
コントローラーにこんな感じで書こうと思うのですがどうでしょうか。
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
>>260
スレ違いだと思うんだけど・・・
スレ違いだと思うんだけど・・・
>>265
> コントローラにはあまり詳細な処理は書きたくない
> 具体的な処理はコンポーネントをこさえて、そちらで処理したい
大事なのはこれらの明確な理由が何なのかってことだと思う。
その会員登録処理がシステムの他の部分からも必要になるならコンポーネントにした方がいいと思うよ。
もしくは他のアプリでも(ほぼ)そのまま使用できるなら。
あとはコントローラとモデル(DAO層)を分離することでテスタビリティを向上させたいとかかなぁ
例えばテストの時はモックコンポーネント使うようにすればデータベースがなくてもコントローラのテストができる。
> コントローラにはあまり詳細な処理は書きたくない
> 具体的な処理はコンポーネントをこさえて、そちらで処理したい
大事なのはこれらの明確な理由が何なのかってことだと思う。
その会員登録処理がシステムの他の部分からも必要になるならコンポーネントにした方がいいと思うよ。
もしくは他のアプリでも(ほぼ)そのまま使用できるなら。
あとはコントローラとモデル(DAO層)を分離することでテスタビリティを向上させたいとかかなぁ
例えばテストの時はモックコンポーネント使うようにすればデータベースがなくてもコントローラのテストができる。
>>266
なるほど。コンポーネントで会員登録処理と思いついた理由は指摘のとおり他のアプリで
いつも同様のことを実装してるのでコンポーネント化してしまおうというのが一番の理由。
それにコントローラ内に細かい条件分岐や処理を書き始めるとものすごくコードが肥大して
メンテナンスがし難いし、もし今後会員登録のフローを同アプリケーションの別箇所でも使い
たいって仕様変更があっても対応しやすいかと。
でも、「会員登録（管理）コンポーネント」なんて作っちゃうとモデルやDBテーブルの構造が
かなり固定化＆依存してしまうのがいやだなだ、と…（AuthComponentみたいにね）
それならばpluginにしちゃえば？って考えることもあるけど、pluginってあんまり使われてないし。
うーむ。
なるほど。コンポーネントで会員登録処理と思いついた理由は指摘のとおり他のアプリで
いつも同様のことを実装してるのでコンポーネント化してしまおうというのが一番の理由。
それにコントローラ内に細かい条件分岐や処理を書き始めるとものすごくコードが肥大して
メンテナンスがし難いし、もし今後会員登録のフローを同アプリケーションの別箇所でも使い
たいって仕様変更があっても対応しやすいかと。
でも、「会員登録（管理）コンポーネント」なんて作っちゃうとモデルやDBテーブルの構造が
かなり固定化＆依存してしまうのがいやだなだ、と…（AuthComponentみたいにね）
それならばpluginにしちゃえば？って考えることもあるけど、pluginってあんまり使われてないし。
うーむ。
>>267
DBテーブルの構造がかなり固定化＆依存
これ内容が会員登録だったらテーブル構造に依存しちゃうのやばいだろ？
会員認証なら固定依存しても、それほど問題ないけど
コンポーネントてそもそもDBテーブルの構造がかなり固定化＆依存してしまうものなんだね
DBテーブルの構造がかなり固定化＆依存
これ内容が会員登録だったらテーブル構造に依存しちゃうのやばいだろ？
会員認証なら固定依存しても、それほど問題ないけど
コンポーネントてそもそもDBテーブルの構造がかなり固定化＆依存してしまうものなんだね
>>267
コンポーネント設計のポイントは、Plug-and-Playを可能にすることであり、独立性を高めることにある
重要となる設計要素は、インターフェースであり、注目すべきは設計要素間の依存関係だと思う
内部実装に依存しない形でコラボレーションをモデル化できるインターフェースが重要じゃないかな
コンポーネント化するということは、結局クラスをグループ化することだからね
クラス間の関連（集合-部分、汎化-特化）と依存関係を意識して設計しないと
物理的にはコンポーネント化したが、論理的にはひとつのシステム全体
ひとつの再利用単位として使わざるを得ないという状況が現れるから
この点で、依存関係の設計はかなり重要
コンポーネント設計のポイントは、Plug-and-Playを可能にすることであり、独立性を高めることにある
重要となる設計要素は、インターフェースであり、注目すべきは設計要素間の依存関係だと思う
内部実装に依存しない形でコラボレーションをモデル化できるインターフェースが重要じゃないかな
コンポーネント化するということは、結局クラスをグループ化することだからね
クラス間の関連（集合-部分、汎化-特化）と依存関係を意識して設計しないと
物理的にはコンポーネント化したが、論理的にはひとつのシステム全体
ひとつの再利用単位として使わざるを得ないという状況が現れるから
この点で、依存関係の設計はかなり重要
>>276
おつかれっす
おつかれっす
findのような感じで、IDを指定してDBデータの更新を
ファンクションはありますか？ イメージとしてはこんな感じで。
$this->Post->hogehoge($id, 'Address'->'Hokkaido');
Model classのファンクションを一通り眺めてみたのですが、
それらしきファンクションを見つける事ができませんでした。
http://api.cakephp.org/class_model.html#d25735e5d69a1c55c58de6df8c06bd9e
ファンクションはありますか？ イメージとしてはこんな感じで。
$this->Post->hogehoge($id, 'Address'->'Hokkaido');
Model classのファンクションを一通り眺めてみたのですが、
それらしきファンクションを見つける事ができませんでした。
http://api.cakephp.org/class_model.html#d25735e5d69a1c55c58de6df8c06bd9e
>>278
ファンクションて何ですか？素人は書き込まないで下さい
ファンクションて何ですか？素人は書き込まないで下さい
>>280
こんなとこで聞くよりも自分でソース見た方が早くね？
こんなとこで聞くよりも自分でソース見た方が早くね？
>>275
会員登録プラグイン、完成したら俺にくれ
会員登録プラグイン、完成したら俺にくれ
>>278
カラム単位の更新でいいなら、saveField。
$this->Post->id = $id;
$this->Post->saveField('Address', 'Hokkaido');
カラム単位の更新でいいなら、saveField。
$this->Post->id = $id;
$this->Post->saveField('Address', 'Hokkaido');
いらなきゃ使わなきゃいいじゃん。
小さい車輪だろうが再開発をしなくて済むなら助かる。
小さい車輪だろうが再開発をしなくて済むなら助かる。
再開発する機会が少ない。激しく無駄
そうじゃなければ、すでに作ってる人たくさんいるよ
そうじゃなければ、すでに作ってる人たくさんいるよ
ほんとにいらなければ何もコメントしないので、たぶん荒らし。
スルー推奨。
しばらく前、本やWebを参考にRoRを使っていたが、cakePHPの方が
使いやすい。
ひょっとしたら、RoRでActiveRecordとかに若干慣れたので、
馴染みやすかっただけかもしんないけど。
スルー推奨。
しばらく前、本やWebを参考にRoRを使っていたが、cakePHPの方が
使いやすい。
ひょっとしたら、RoRでActiveRecordとかに若干慣れたので、
馴染みやすかっただけかもしんないけど。
Cakeのプラグインって、なにか有名なのってあったっけ
なんのためにプラ銀機能なんて実装されてんの？
なんのためにプラ銀機能なんて実装されてんの？
コントローラ全体じゃなくてメソッド単位でヘルパー、コンポーネント呼び出すにはどうすればいい？
会員登録ページのメソッドにアクセスしてるにもかかわらず
コントローラでPaginationコンポーネントを定義していれば
ページ処理の関わるクラスがnewされるんでしょ
会員登録ページのメソッドにアクセスしてるにもかかわらず
コントローラでPaginationコンポーネントを定義していれば
ページ処理の関わるクラスがnewされるんでしょ
ヘルパーは細かく考えずにコントローラ単位で呼び出すのがCake流
コンポーネントやモデルはヘルパーに比べればメソッド単位で呼び出しやすいけど
こっちも深く考えずにコントローラ単位で呼び出すんだ
多分
コンポーネントやモデルはヘルパーに比べればメソッド単位で呼び出しやすいけど
こっちも深く考えずにコントローラ単位で呼び出すんだ
多分
例えばググレカスアクションでほげヘルパーを呼び出す場合
function gugurekasu() {
App::import('Helper', 'Hoge');
$ajax = new HogeHelper();
}
function gugurekasu() {
App::import('Helper', 'Hoge');
$ajax = new HogeHelper();
}
まあ、そんなに特定のアクションでだけ
ヘルパーとか呼び出したいのなら、
そういうコンポーネントを作ればいいんじゃないのかな？
コンストラクタあたりで、url見てごにゃごちゃすれば出来るでしょう？
ヘルパーとか呼び出したいのなら、
そういうコンポーネントを作ればいいんじゃないのかな？
コンストラクタあたりで、url見てごにゃごちゃすれば出来るでしょう？
>>294
むしろ$ajaxに突っ込んで欲しかったな
むしろ$ajaxに突っ込んで欲しかったな
モデルってあんまりごちゃごちゃ書きたくないよな、dbdesigner2cakeとか使ってるとメンテナンスの面からとく。
だからといってコントローラにごちゃごちゃとロジックを書き並べたくないので
コンポーネントにすべてモデルを操作するカスタムメソッドを記述してます。
これって俺だけ？
だからといってコントローラにごちゃごちゃとロジックを書き並べたくないので
コンポーネントにすべてモデルを操作するカスタムメソッドを記述してます。
これって俺だけ？
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
php スレッド一覧へ類似してるかもしれないスレッド
- 【PHP】フレームワーク CakePHP 4ホール目【v1.2】 (1001) - [89%] - 2008/12/19 21:06 ○
- 【PHP】フレームワーク CakePHP 5ホール目【v1.2】 (985) - [89%] - 2009/3/7 4:53 ☆
- 【PHP】フレームワーク CakePHP 7ホール目【v1.2】 (1001) - [89%] - 2010/3/18 1:18 ○
- 【PHP】フレームワーク CakePHP 6ホール目【v1.2】 (933) - [89%] - 2009/8/19 2:06 ○
- 【PHP】フレームワーク CakePHP 12ホール目【笑】 (1001) - [87%] - 2011/11/8 7:01
- 【PHP】フレームワーク CakePHP 13ホール目【v2.0】 (995) - [86%] - 2012/4/23 21:16 ○
- 【PHP】フレームワーク CakePHP 17ホール目【v3α】 (955) - [84%] - 2016/11/15 20:45
- 【PHP】フレームワーク CakePHP 17ホール目【v2.4】 (984) - [84%] - 2015/1/10 2:45
- 【PHP】フレームワーク CakePHP 16ホール目【v2.4】 (1001) - [84%] - 2014/3/3 3:00
- 【PHP】フレームワーク CakePHP 15ホール目【v2.2】 (985) - [84%] - 2013/9/7 8:30
- 【PHP】フレームワーク CakePHP 10ホール目【v1.3】 (1001) - [84%] - 2011/2/13 8:32
- 【PHP】フレームワーク CakePHP 11ホール目【v1.3】 (1001) - [84%] - 2011/6/30 22:32
- 【PHP】フレームワーク CakePHP 19ホール目【v3.3】 (844) - [84%] - 2023/2/2 14:30
- 【PHP】フレームワーク CakePHP 14ホール目【v2.1】 (1001) - [84%] - 2012/12/3 19:16
トップメニューへ / →のくす牧場書庫について