【PHP】フレームワーク CakePHP 3ホール目【本命】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2008/03/14(金) 15:16:00ID:HF9x5ODX10分で作るCakePHPアプリ for Windows
http://p4life.jp/cake/
マニュアル日本語化
http://www.cakephp.jp/doc/
日本語フォーラム
http://cakephp.jp/modules/newbb/
あとこのへんとか（初心者向けTIPS）
http://www.avatarfinancial.com/pages/cake/
CakePHP入門リンク集
ttp://pub.studio15.jp/2007/11/13/cakephp-links/
【PHP】フレームワーク CakePHP 2ホール目
http://pc11.2ch.net/test/read.cgi/php/1194976228/
【PHP】フレームワーク CakePHP
http://pc11.2ch.net/test/read.cgi/php/1163850802/
0269nobodyさん
2008/03/22(土) 10:19:47ID:???DBテーブルの構造がかなり固定化＆依存
これ内容が会員登録だったらテーブル構造に依存しちゃうのやばいだろ？
会員認証なら固定依存しても、それほど問題ないけど
コンポーネントてそもそもDBテーブルの構造がかなり固定化＆依存してしまうものなんだね
0270nobodyさん
2008/03/22(土) 10:52:32ID:???コンポーネント設計のポイントは、Plug-and-Playを可能にすることであり、独立性を高めることにある
重要となる設計要素は、インターフェースであり、注目すべきは設計要素間の依存関係だと思う
内部実装に依存しない形でコラボレーションをモデル化できるインターフェースが重要じゃないかな
コンポーネント化するということは、結局クラスをグループ化することだからね
クラス間の関連（集合-部分、汎化-特化）と依存関係を意識して設計しないと
物理的にはコンポーネント化したが、論理的にはひとつのシステム全体
ひとつの再利用単位として使わざるを得ないという状況が現れるから
この点で、依存関係の設計はかなり重要
0271nobodyさん
2008/03/22(土) 11:26:27ID:???モックコンポーネント
あまり聞かない、組み合わせだけどｗ
モックとコンポーネント入れ替えするものじゃないの？
0272nobodyさん
2008/03/22(土) 11:49:52ID:???0273nobodyさん
2008/03/22(土) 19:56:20ID:rTbTxKR5「配布できる」と書いてあるくせに、プラグイン配布サイトって見たことないやと思って。
「会員登録プラグイン」とかあるといいのになー
会員登録コンポーネントの件、結局ユーザーテーブルを分けて（users:ログインIDとパスワードだけ、user_profiles:その他のプロフィール項目）
コンポーネントで固定化するのはusersテーブルを主にして、user_profilesの方はアプリケーション毎に
自由に定義できるような仕様でコンポーネントを書いてみようかと思っています。
0274nobodyさん
2008/03/22(土) 20:52:09ID:???そういうこと。テストの時はモックを使うようにする。
「コンポーネントのモック」って意味でモックコンポーネントって言った。
0275nobodyさん
2008/03/22(土) 21:01:00ID:???会員登録プラグイン
何度も使うような処理でも無いし面倒な処理でもないからなあ
個人的には確認画面やらページ送りやら何度も使う場面のあるプラグインもしくは
コンポーネントが欲しい
0276nobodyさん
2008/03/23(日) 01:31:09ID:???yamlの空白に少しはまった
0278nobodyさん
2008/03/23(日) 12:24:28ID:???ファンクションはありますか？ イメージとしてはこんな感じで。
$this->Post->hogehoge($id, 'Address'->'Hokkaido');
Model classのファンクションを一通り眺めてみたのですが、
それらしきファンクションを見つける事ができませんでした。
http://api.cakephp.org/class_model.html#d25735e5d69a1c55c58de6df8c06bd9e
0280278
2008/03/23(日) 13:46:28ID:9wMqWTzf先に挙げたURLで、「Public Member Functions」と記述されていたので、
ファンクションと書かせてもらいました。
methodと言えばいいですか？
既存のものでいうと、findAllやsaveなどの事です。
ご存じでしたらお教え下さい。
0282nobodyさん
2008/03/23(日) 21:00:13ID:xiSCrZA7会員登録プラグイン、完成したら俺にくれ
0284nobodyさん
2008/03/23(日) 23:07:41ID:???カラム単位の更新でいいなら、saveField。
$this->Post->id = $id;
$this->Post->saveField('Address', 'Hokkaido');
0285nobodyさん
2008/03/23(日) 23:25:30ID:???小さい車輪だろうが再開発をしなくて済むなら助かる。
0286nobodyさん
2008/03/24(月) 00:14:26ID:???そうじゃなければ、すでに作ってる人たくさんいるよ
0287nobodyさん
2008/03/24(月) 00:19:02ID:???スルー推奨。
しばらく前、本やWebを参考にRoRを使っていたが、cakePHPの方が
使いやすい。
ひょっとしたら、RoRでActiveRecordとかに若干慣れたので、
馴染みやすかっただけかもしんないけど。
0288nobodyさん
2008/03/24(月) 00:22:17ID:gAnd/HKbなんのためにプラ銀機能なんて実装されてんの？
0289nobodyさん
2008/03/24(月) 03:29:33ID:???0290nobodyさん
2008/03/24(月) 03:37:25ID:???会員登録ページのメソッドにアクセスしてるにもかかわらず
コントローラでPaginationコンポーネントを定義していれば
ページ処理の関わるクラスがnewされるんでしょ
0291nobodyさん
2008/03/24(月) 13:06:37ID:???コンポーネントやモデルはヘルパーに比べればメソッド単位で呼び出しやすいけど
こっちも深く考えずにコントローラ単位で呼び出すんだ
多分
0292nobodyさん
2008/03/24(月) 13:16:08ID:???function gugurekasu() {
App::import('Helper', 'Hoge');
$ajax = new HogeHelper();
}
0293nobodyさん
2008/03/24(月) 20:55:32ID:???ヘルパーとか呼び出したいのなら、
そういうコンポーネントを作ればいいんじゃないのかな？
コンストラクタあたりで、url見てごにゃごちゃすれば出来るでしょう？
0296nobodyさん
2008/03/25(火) 10:30:40ID:Qe2AafnSだからといってコントローラにごちゃごちゃとロジックを書き並べたくないので
コンポーネントにすべてモデルを操作するカスタムメソッドを記述してます。
これって俺だけ？
0297nobodyさん
2008/03/25(火) 10:37:30ID:???まずいケーキだってケーキ様が言っている。
http://cakephp.org/files/OCPHP.pdf
0298nobodyさん
2008/03/25(火) 10:46:51ID:???ケーキがどうのこうのいおうが
自分の見やすい書き方が一番
たとえば１万step以下のコードなら
全部コントローラに書いた方がいい、みたいなね！
0299nobodyさん
2008/03/25(火) 10:55:58ID:Qe2AafnS3ページ目？ こんなにモデルに書くもんかね…
俺だったらｃとｍの間のコンポーネントをずっしり書くな。別のプロジェクトにも使いまわしできるし。
コントローラだとほぼ、使いまわせないしな。
0300nobodyさん
2008/03/25(火) 11:02:26ID:???0301nobodyさん
2008/03/25(火) 11:05:24ID:???コントローラに関する再利用性の高いメソッドはコンポーネント
モデルに関する再利用性の高いメソッドはビヘイビア
再利用性が高いロジックじゃないとダメ
そのロジックがコントローラ側かモデル側かどっちに属するかを間違えるとダメ
0305nobodyさん
2008/03/25(火) 11:13:20ID:Qe2AafnS0306nobodyさん
2008/03/25(火) 11:14:25ID:???コンポーネントにすべてモデルを操作するカスタムメソッドを記述してます
これダメだろ？再利用性の高さとか無視してるやん
0307nobodyさん
2008/03/25(火) 11:17:23ID:???それだけでもオワッテルｗ
0308nobodyさん
2008/03/25(火) 11:22:06ID:???男性・女性・オカマとか
こういうセレクトに必要な初期データはどこへ入れるの？
0309nobodyさん
2008/03/25(火) 11:38:31ID:???spyc重くね？
>>308
とりあえずモデル作ってfind('list')呼んでセレクトボックスへ流す。
都道府県データなんてほぼ100%変更出ないからデータの中身は定数でもいいし
郵便番号検索とか使うアテがあるならデータベース使う。
中で何やってるかは置いといて、ともかくモデルから呼べる事が大事。
0310nobodyさん
2008/03/25(火) 11:42:07ID:???モデルのメソッドの中に都道府県データをいれて
呼び出してもＯＫ？
もしくはＤＢからひっぱる、それ以外に方法はわからない
0311nobodyさん
2008/03/25(火) 11:44:21ID:???呼び出すときにモデル経由でincludeして呼び出すのがいいのかな
0312nobodyさん
2008/03/25(火) 12:29:56ID:???> spyc重くね？
書くのはYAMLでもキャッシュとしてPHPのシリアライズデータに
変換してそれを読み込むから重くない。
0313nobodyさん
2008/03/25(火) 12:34:26ID:???ケーキを使っている以上ケーキ様の言うことは絶対です。
コンポーネントにいろいろ書くとどれだけテストが大変になるか。
0314nobodyさん
2008/03/25(火) 12:38:32ID:???> 男性・女性・オカマとか
これじゃ足りないな。
現在の肉体的性別 男・女
生まれたときの肉体的性別 男・女
現在の精神的性別 男・女
生まれたときの精神的性別 男・女
好きな性別 男・女・両方・肉体が男・肉体が女
まだ足りないかもな！
0317nobodyさん
2008/03/25(火) 16:31:35ID:???コンストラクタ内で先に
parent::__construct();
を呼ばないとダメだよ
なぜ？て
それは>>318が答えてくれるはず
0318nobodyさん
2008/03/25(火) 17:10:42ID:???0319nobodyさん
2008/03/25(火) 17:42:53ID:???それぞれが間違いとも正解とも言えないから余計めんどくさい。
もっと縛りがキツければ良いのに。
0321nobodyさん
2008/03/25(火) 18:24:02ID:Qe2AafnSEmailコンポーネントと連携して"emailable=1"を判別してメールするビヘイビアだとか、
ソフトデリート(＝削除フラグ=1を削除）を実装したビヘイビアとかのサンプルは目にした
んだけど、もっと実践に役立つ使い道ってどんな風なの？？
0322nobodyさん
2008/03/26(水) 01:26:50ID:???ユーザーが入力した情報を加工したものを別フィールドに自動的に保存する。
データベースのセオリーからいえば計算で求められる物なのでビューやトリガーを使うところだが、
パフォーマンスを重視＆汎用性を高めるためにこうしている。
あとどこかでぐぐって見つけた画像を保存するビヘイビア。
あるテーブルに保存したら、自動的にほかのテーブルにメタ情報を保存するビヘイビア
つまりトリガーの代わりだね。
文字コード変換ビヘイビア
仕様が変わって使っていないが、一つのフィールドに複数の値を入れられる配列型フィールドを作るビヘイビア。
（一対多のテーブルを作れというなよ？そんなJOINが発生する重い処理を作りたくないこともあるんだ。
SQL99 で標準規格化されたしね。）それの応用でオブジェクト（シリアライズ）型
それともうひとつあるのだが、これはちょっとアイデア賞物だと思うので自分のブログで書きたいｗ
結構いろいろ使っているなｗ 総論としてデータベースの機能を拡張したいときに使っている。
0323nobodyさん
2008/03/26(水) 02:10:48ID:???日本語でおｋ
あいかわらず文章下手糞やなｗ
単純なことをわかりにくい表現するの好きやな
前スレから全く変わってねーな
0325nobodyさん
2008/03/26(水) 02:29:03ID:???ユーザーが入力した情報を加工したものを別フィールドに自動的に保存する。
この自動的て具体的にどういう意味？
0326nobodyさん
2008/03/26(水) 02:34:57ID:???ユーザーが入力した情報を加工したものを別フィールドに自動的に保存する。
これは前スレで自作ヘルパーでやってなかったか？
パフォーマンスを重視＆汎用性を高めるというのに具体的内容が欲しい
0327nobodyさん
2008/03/26(水) 02:40:36ID:???一つのフィールドに複数の値を入れられる配列型フィールド
ＳＮＳのような大規模サイトでもこれ使う機会なんて滅多にないんだが、何作ってんの？
0330nobodyさん
2008/03/26(水) 03:12:41ID:???それともうひとつあるのだが、これはちょっとアイデア賞物だと思うので自分のブログで書きたいｗ
恒例自慢きたこれｗ
0331nobodyさん
2008/03/26(水) 03:36:11ID:???なんだこの過剰反応ぶりｗ
みるからに同一人物のようだが、
ただの使用例に必死すぎだろｗ
0332nobodyさん
2008/03/26(水) 03:41:59ID:???激しく必要のない○○○じゃね？
なんにでも当てはまるなｗ
無理やり反論しようとして滑ってる。
0334nobodyさん
2008/03/26(水) 03:51:47ID:???0336nobodyさん
2008/03/26(水) 04:38:16ID:pkIggipTシーケンス図やクラス図なんかどんな風に記述してるかとか見せてもらえると
参考になります。
0337nobodyさん
2008/03/26(水) 04:51:55ID:???UMLを使うと従来の方法より効率が落ちる時もある。
なぜなら、従来なら手書きで適当に書いてきた図をUMLでどうやって書けばいいのか調べなければならないから。
書き方が全部頭の中に入った後でなら従来よりスムーズに開発ができるようになるかもしれない
が、しかし、それまでは相当の苦労が必要ｗ
オブジェクト指向開発とUMLとはまた別の話でUMLはオブジェクト指向開発の道具にすぎない
0339nobodyさん
2008/03/26(水) 05:04:03ID:???そんなクラスが複雑じゃないやん
0340nobodyさん
2008/03/26(水) 05:24:25ID:???0342nobodyさん
2008/03/26(水) 10:50:05ID:???だがそれは個人の話であって統計的な意味は無い。
検索結果のほうがまだ意味があるな
PHP UML の検索結果 約 957,000 件中 1 - 10 件目 (0.03 秒)
Java UML の検索結果 約 593,000 件中 1 - 10 件目 (0.04 秒)
C# UML の検索結果 約 404,000 件中 1 - 10 件目 (0.04 秒)
0343nobodyさん
2008/03/26(水) 11:29:28ID:???0344nobodyさん
2008/03/26(水) 11:31:39ID:???0346nobodyさん
2008/03/26(水) 11:58:29ID:???複雑になってくるクラス間の関連性の構造の手助けとしてＵＭＬを活用することが多い
だから>>339のいってるように複雑なクラスで無ければ必ずしもＵＭＬが必要とは思わない
0347nobodyさん
2008/03/26(水) 12:17:07ID:???実装者が未熟な場合か、処理が複雑なときだけかな。
クラスダイアグラムはモデル限定でこれもテーブル構成が複雑なときだけ。
ユースケースは文書に起こして仕様書にするので必須。
PHPのクラスを自動生成してくれる奴なかったっけ?
あれでCakeのモデルを自動的に管理してくれると楽かも...楽じゃないかw
0348nobodyさん
2008/03/26(水) 12:24:40ID:???書いているだけでしかないからなぁ。
それならコードで書いてコードからクラス図を自動生成したほうが楽。
0349nobodyさん
2008/03/26(水) 12:38:45ID:???正確にはEJBを使った場合だが、同じものを作るにしても
無意味に複雑になりすぎる。
あれじゃあ、UMLが必要になるのもわかる。
0350nobodyさん
2008/03/26(水) 13:44:26ID:ktIW9Uv7それだから「できました」とかいいながらテストしたらバグ出まくりのプログラムなんか量産しちゃうんだよwwww
UMLじゃなくてもいいが、実装前に詳細なロジックを書き起こしてからコードつくるのは常識だろ。
時間がかかる、めんどくさい、頭の中にもう仕様書書いてあるから、という奴に限ってたいした技術力じゃないんだよな。
設計書ってのはコーディング作業が楽になるだけでなく、チーム関係者との意識共有や、リリース後しばらくたってメンテが必要になった時に効果がでるもんだぜ。
プロとして仕事でやってるならば当たり前だと思ってるが、ここにはプロはいないのか？
0351nobodyさん
2008/03/26(水) 14:32:19ID:???0352nobodyさん
2008/03/26(水) 15:25:48ID:???実装前に詳細なロジックを書き起こしてからコードつくるのは常識だろ
それお前だけの常識乙ｗ
CakePHPのような小規模案件に無理があるぞお前ｗ
0355nobodyさん
2008/03/26(水) 15:37:50ID:???わざわざＵＭＬとか工数伸びるだけやんけ
そんなんで、ほんまに黒字になってんのかｗ
0356nobodyさん
2008/03/26(水) 15:41:14ID:???スレ違いながら言わせてもらうと・・
実際、開発しながら見えてくる事って多いよね。
キチンと設計や仕様固めが出来ないまま、見切りスタートを切ってしまうことも多々。
問題は、その仕様の追加、変更に対応出来るように設計する事だよ。
0357nobodyさん
2008/03/26(水) 16:12:51ID:???俺は書き方すら知らないけど。
作る前に一応メモに何をどうするかを書き出して、その通りに作ってくね。
あまりに自分の頭の中だけで作ると変数とか何を使ったかわからなくなったり。
イラレで仕様書とか作るのが激しくめんどい。
よって手書きで自分はやってます。
0358nobodyさん
2008/03/26(水) 16:15:44ID:???w
0359nobodyさん
2008/03/26(水) 17:32:25ID:???最低限、要求定義書とユースケースとビジネスロジック(=モデル)の関係図とそれを基にしたスキーマ設計位は必要じゃねーの
打ち合わせ段階で作りまくるじゃん、そんなの
どやってクライアントのイチャモンに対応してるの？
>>357
イラレで仕様書とか正気？
0360nobodyさん
2008/03/26(水) 17:56:28ID:???よって俺もexcel＆イラレだな。
0361nobodyさん
2008/03/26(水) 17:58:19ID:???概要みたいなもんだからね。
たとえば関数をすべてコーディング前に列挙できるかといったらまず不可能
プロのプログラマはコードで設計するんだよ。
鉛筆で図を書くか、キーボードでコードで書くかの違い。
0362nobodyさん
2008/03/26(水) 18:01:13ID:???0363nobodyさん
2008/03/26(水) 19:04:34ID:???○プロはソースに意味のあるコメントを残す。
0366nobodyさん
2008/03/26(水) 21:07:55ID:???■ このスレッドは過去ログ倉庫に格納されています