【PHP】フレームワーク CakePHP 4ホール目【v1.2】
■ このスレッドは過去ログ倉庫に格納されています
0001nobodyさん
2008/06/20(金) 01:24:40ID:???10分で作るCakePHPアプリ for Windows
http://p4life.jp/cake/
マニュアル日本語化
http://www.cakephp.jp/doc/
Cookbook :: 1.2 Collection :: マニュアル
http://book.cakephp.org/ja
日本語フォーラム
http://cakephp.jp/modules/newbb/
あとこのへんとか（初心者向けTIPS）
http://www.avatarfinancial.com/pages/cake/
CakePHP入門リンク集
ttp://pub.studio15.jp/2007/11/13/cakephp-links/
【PHP】フレームワーク CakePHP 3ホール目【本命】
http://pc11.2ch.net/test/read.cgi/php/1205475360/
【PHP】フレームワーク CakePHP 2ホール目
http://pc11.2ch.net/test/read.cgi/php/1194976228/
【PHP】フレームワーク CakePHP
http://pc11.2ch.net/test/read.cgi/php/1163850802/
0552nobodyさん
2008/11/07(金) 23:32:23ID:???そもそもmysqlは画像データを格納するために作っていないから
画像はフォルダに入れて管理した方がいいと
mysql作者が語ってるのに。
そんな自分もかけだしのときはmysqlに画像データ入れてました
管理は楽だけどね。かなりの負荷がかかる。
Bakeとか使う人も素人くさいと思う。
0554nobodyさん
2008/11/08(土) 00:12:16ID:???http://book.cakephp.org/ja/view/46/Routes%E3%81%AE%E8%A8%AD%E5%AE%9A
Routes追加すればURL上は階層化されてるように見せることは出来るが、名前の衝突は回避できない。
コントローラ名にパス名も入れればユニークになって衝突回避出来なくもないが、色々面倒なことになる。
0555nobodyさん
2008/11/08(土) 00:14:48ID:???使うのはスキーマ検証時くらいだけど。
0556nobodyさん
2008/11/08(土) 00:17:44ID:???0557nobodyさん
2008/11/08(土) 00:19:20ID:???case by caseだとおもうけど
DBでファイルのパス管理してたらそのファイルが消されてたりとか。
かといって参照頻度が高いときはDBに置きたくないしな
さすがにデザインとかで使うような画像は普通に置いとくけどさ
0558nobodyさん
2008/11/08(土) 01:37:22ID:???DBに入れておいて、参照されたらキャッシュを作り、そのキャッシュを送信するって方法もあるらしい。
2回目以降は早いし、ファイルが消えても問題ない。
0559nobodyさん
2008/11/08(土) 02:27:53ID:???0561nobodyさん
2008/11/08(土) 03:22:53ID:???0562nobodyさん
2008/11/08(土) 07:55:27ID:???画像もDBに格納して管理する −扱いがめんどうなLOB(ラージオブジェクト)は使わない方法も含め
http://neta.ywcafe.net/000774.html
0563nobodyさん
2008/11/08(土) 11:22:34ID:???mysqlは画像を格納するという目的で設計されてないからね
だから画像をＤＢに入れるのが悪いというのではなく
画像をmysqlに入れるということがナンセンス
0564nobodyさん
2008/11/08(土) 11:26:06ID:???画像格納させたいならoracleとかの方が合理的だと思うよ
0565nobodyさん
2008/11/08(土) 11:33:20ID:???ＤＢと連携させて管理するのが面倒だけど、そこまで面倒な管理とも思えない
画像はデータの一つだからＤＢ格納がよいという理念なら
htmlもcssも全部ＤＢに入れよということになる
0566nobodyさん
2008/11/08(土) 11:38:58ID:???ＤＢの持つ性能とバランスをどこまで考えてるの疑問に思う
0567nobodyさん
2008/11/08(土) 11:42:47ID:???0568nobodyさん
2008/11/08(土) 12:05:42ID:???通常の Web サーバセットアップを使用する場合は、画像をファイルとして格納する。
言い換えると、データベース内にはファイル参照のみを格納する。この主な理由は、
通常の Web サーバのほうがデータベースコンテンツと比較してファイルのキャッシュに優れているためである。
このため、ファイルを使用したほうがシステムの高速化を容易に図れる。
0569nobodyさん
2008/11/08(土) 12:09:44ID:???ザのデータを一括管理できるというメリットしか存在しないと思うけどな。
Railsのときはそうやってて、非常に便利だった。
0570nobodyさん
2008/11/08(土) 14:24:18ID:???> コントローラ名にパス名も入れればユニークになって衝突回避出来なくもないが、色々面倒なことになる。
了解です。ありがとうございます。
今回はbootstrap.phpの$controllerPathsでやって、名前の衝突についてはその
都度対処することにしようと思います。
0571nobodyさん
2008/11/08(土) 15:12:49ID:???B hasMany C
で
C belongsTo D
みたいなときのリレーションの貼り方が判らないんですが、
そもそも可能なんでしょうか？
（Aを基点にA〜Dのテーブルからデータを取ってくる想定）
SQL直書きでは勿論可能ですが。
0572nobodyさん
2008/11/08(土) 15:56:39ID:???そこまでしてリレーションに拘るのは返って
生産性を落とす可能性があるから
要はバランスですね
どこからＳＱＬｌ直書きにするかの線引きはね
0573nobodyさん
2008/11/08(土) 16:42:40ID:???アクセス頻度やキャシュの実装、使い方や状況によって向いてる場合もあろう。
0574nobodyさん
2008/11/08(土) 17:08:34ID:???簡単に出来るのなら採用したかったのですが・・・
0575nobodyさん
2008/11/08(土) 18:47:57ID:???履歴書の写真とか。
0576nobodyさん
2008/11/08(土) 18:54:20ID:???置くわけでは無いと思うが。
認証チェック経由でファイルを返すのが普通でしょ。
0577nobodyさん
2008/11/08(土) 19:06:19ID:???0578nobodyさん
2008/11/08(土) 19:11:50ID:???ファイルパスのみＤＢに突っ込んで画像はファイルシステムから読み出すようにすりゃ良いんじゃないの？
画像データそのものをＤＢに突っ込む必要があるとしたら、
バイナリデータで検索する場合しかなくない？
0579578
2008/11/08(土) 19:15:44ID:???例えばＤＢだとデータをまとめて暗号化するようなソリューションがある場合があるが
ファイルシステムに保存するとそういう枠組みから漏れてしまう
まあファイルシステムドライバで暗号化すれば良いだけなんだけど
ドライバ方式とＤＢ方式の差異はパフォーマンスくらいか
それも特定ディレクトリだけ暗号化するようにすれば良いだけか
0580nobodyさん
2008/11/08(土) 19:26:04ID:???// 何かしらの認証チェック...
header("Content-type: ...");
...
readfile( 直接ブラウズできないパスの画像ファイル );
?>
な処理をimgのsrcに指定。
0581nobodyさん
2008/11/08(土) 19:32:38ID:???php⇔hdd間での画像データのやり取りをどうするかって事だよね
0583nobodyさん
2008/11/09(日) 06:03:18ID:???同じくらい面倒だ、ＤＢ画像管理が最高に楽じゃない限り
パフォーマンスのいいファイルシステムになる
0584nobodyさん
2008/11/09(日) 06:10:19ID:???0586nobodyさん
2008/11/09(日) 13:38:34ID:???> 画像はデータの一つだからＤＢ格納がよいという理念なら
> htmlもcssも全部ＤＢに入れよということになる
画像はM
htmlやcssはV
DBには入れませんが。。。
0587nobodyさん
2008/11/09(日) 13:55:11ID:???リリース時で固定）は別物だと思うが。
前者をDBで一元管理できると便利だよ。
まあ抵抗のある人に無理強いするつもりはないし、個々人の自由だと思うけど。
自分はCakePHPでもこれがやれるならやりたいなあ。
何とか実現できないものか。
0588nobodyさん
2008/11/09(日) 14:11:02ID:???条件があえば、DB管理で一元管理でも良いと思う。
この辺を思い出した。
ttp://neta.ywcafe.net/000774.html
ttp://blog.livedoor.jp/techblog/archives/64648176.html
0589nobodyさん
2008/11/09(日) 15:42:14ID:???0590nobodyさん
2008/11/09(日) 15:47:24ID:???ページ上に表示されるような画像はＶだよ
そしてページ上に表示されない画像ならＷＥＢシステムの中に入れておくべきものじゃない
画像でありながらＭになりうるのは、画像検索システムのようなものだけ
0591nobodyさん
2008/11/09(日) 15:48:39ID:???それをＷＥＢ上からログインして観覧するようなシステムがあるならＶ
一切使い道が無いならＷＥＢシステム外で保管しておくべきもの
無いと思うけどその画像で画像検索するならＭ
0592nobodyさん
2008/11/09(日) 23:20:30ID:???検索対象じゃないとMになれないの？
↓そう読み取れなかったが
http://ja.wikipedia.org/wiki/Model_View_Controller
0593nobodyさん
2008/11/09(日) 23:25:24ID:???要件次第だと思うよ。
0594nobodyさん
2008/11/11(火) 09:18:04ID:???ファイルをバイナリーデータに変えたものがＭである
0596nobodyさん
2008/11/11(火) 11:39:47ID:???Vはデータを表示する仕組み
Cはデータを操作する仕組み
画像はデータなのでそのどれでもないと思うが
0597nobodyさん
2008/11/11(火) 11:48:43ID:???辞書には
> あつか・う〔あつかふ〕【扱う】
> 道具・機械などを、使ったり操作したりする。取り扱う。
ってあったっす
0598nobodyさん
2008/11/11(火) 12:46:42ID:???Mはデータの出し入れや変換、型決めなど広範囲に扱える
0599nobodyさん
2008/11/11(火) 18:28:03ID:???0600nobodyさん
2008/11/11(火) 18:41:57ID:???0601nobodyさん
2008/11/12(水) 01:29:19ID:???コントローラはモデルで引っ張ったデータをチェックしてビューに渡すだけだな
0602nobodyさん
2008/11/12(水) 09:05:32ID:???モデルに書くと生産性が落ちる
なぜなら
再利用できるように関数化させるのが手間
再利用が２回程度ならコントローラ上でコピペが最短
0603nobodyさん
2008/11/12(水) 09:12:09ID:???総体的にコード量が多くなる。
なぜなら
symfonyのように
ＭとＶのやりとりが直接出来ないから
Ｃに橋渡し的なコードを書かないといけない分
コード量が増える
symfonyのうような仕様なら
モデルをどんどん厚くすべきだが
CakePHPの場合は
モデルを厚くしすぎるのも
作業効率が落ちると思う
0604nobodyさん
2008/11/12(水) 17:43:12ID:???ここ見るとfind系が全部find()に統合されたって書いてあるけど、
findAllByって使っちゃっていいの？
特に非推奨とは書いてないけど。
findByとfindAllByだと配列で条件指定する新しい形式が使えなくて
nullを並べる旧形式のままだから、条件指定方法が統一できなくて
ちょっと気持ち悪いんだけど…
新形式の条件指定に対応しないってことは、そのうちマジックメソッド自体が
消える予定なのかな。
調べてみたけど、日本語だとこれくらいしか記事がない
http://d.hatena.ne.jp/ichiichinini/20081104/1225832073
0605nobodyさん
2008/11/12(水) 17:55:00ID:???0606nobodyさん
2008/11/12(水) 20:14:45ID:???find系てfind()でほとんど出来ると思うので
最初から意味の無さそうな機能だなとは思ってた
したがってfind()で統一してる人ばかりだと思うんで
どうでもいいよ
0607nobodyさん
2008/11/12(水) 20:23:16ID:???可読性とコーディング量は改善されるけど。
いつも使わない関数だとすれば、単なる無駄
0608nobodyさん
2008/11/12(水) 20:32:06ID:???データのやりとりが配列思考なところなんだよね
というのはphp自体が壊れたオブジェクト指向だから
配列思考型のフレームワークはphpにはピッタリだと思う。
あと配列思考型は中小規模にも適してる
CakePHP自体が中小規模を対象として設計されてると思う
rubyは完成されたオブジェクト指向言語だから
rorのようなオブジェクト指向型でのデータのやりとりがマッチする
0609nobodyさん
2008/11/12(水) 20:36:33ID:???> ＭとＶのやりとりが直接出来ないから
つーかやったらいかんだろｗ
MVCって何か知ってるか。
まあそんなにやりたきゃ、viewにmodelを渡せばいいだけ。
0611nobodyさん
2008/11/12(水) 21:43:29ID:???0613604
2008/11/13(木) 11:26:34ID:???やっぱりfind()で統一の方向なのか…
AND検索はマジックメソッド使った方が書きやすいから好きだったんだけど。
今後はfind()で統一してみる。
0614nobodyさん
2008/11/13(木) 12:56:14ID:???いいと思うんだけどなぁ・・・。
再利用するかしないかは別として。
まぁ、個人的な意見なのですが。
0615nobodyさん
2008/11/13(木) 16:20:24ID:???0616nobodyさん
2008/11/13(木) 18:25:42ID:???0617nobodyさん
2008/11/13(木) 20:23:44ID:???生産性を第一に考えると関数化してモデルに入れるよりも
コントローラ内で同じ構文を連続コピペした方が早い場合もあるんだよね。
例えば、納期がほとんどないという、追い込まれた状況なら
わざわざ関数化するのも時間がかかるじゃん、そういう意味もあるんだな
時間が限りなくあるなら、出来るだけ関数化してモデルに入れるのがベストだけどさ
0618nobodyさん
2008/11/13(木) 20:26:25ID:???0619nobodyさん
2008/11/13(木) 20:32:36ID:???CakePHPでの経験が無いと、いきなりは、逆に時間がかかり
重要である生産性が落ちると思う。
経験を積みながら、少しずつリファクタリングすてモデルを厚くしていく方法がベストかな
0620nobodyさん
2008/11/13(木) 22:47:32ID:???コントローラーにコードを書きまくってたんだが、
徐々に慣れてきてからは、モデルを厚くする方が良さそうだなという感想。
0621nobodyさん
2008/11/14(金) 15:37:31ID:???って現象に陥った人っていらっしゃいますか？
ブラウザ？と思ったんですが、どのブラウザでも真っ白になっちゃいます。
1.1系で試したらうまくいくのに…。
mod_rewriteも有効、phpのバージョンもOK、パーミッションも変更済み。
.htaccessの内容も確認しましたが、1.1と1.2で同じでした。
同じ現象にぶち当たった方、いらっしゃったら教えてください＞＜
0622nobodyさん
2008/11/14(金) 15:43:57ID:???0623nobodyさん
2008/11/14(金) 15:59:49ID:???0624621
2008/11/14(金) 16:23:40ID:???うーん、落としてきたモノをそのまま展開してるだけなんですよね。
どっかで間違えたのか・・・
>>623
デバッグレベルは3にしてあります。
それでも真っ白なんです＞＜
0625nobodyさん
2008/11/14(金) 16:25:23ID:???PHPかApacheのログ見れ。
多分、cakeの問題ではない。
0627nobodyさん
2008/11/14(金) 17:34:28ID:???0628nobodyさん
2008/11/14(金) 17:36:59ID:???エラー無いのに何も表示されないなら何も出力しない処理に成功してるって事だろ
0629621
2008/11/14(金) 18:29:19ID:???確認したんですが、それもなさそうです。。
>>628
そうですねｗ
いや、設定かなぁと。RewriteBaseとか。
でも別のサーバでは特に追記しなくても普通に動くので、なんだろう、と。
0630nobodyさん
2008/11/14(金) 19:48:22ID:???結局訳が分からず、一念発起して、1.2で書き直したけど。
同じかなあ？
0631630
2008/11/14(金) 19:50:04ID:???0632nobodyさん
2008/11/14(金) 19:51:34ID:???0633nobodyさん
2008/11/14(金) 22:25:29ID:???Eclipse+XDebug、NetBeansでCake mod_rewite無し版だとちゃんと使えるんだが・・・
0634nobodyさん
2008/11/15(土) 00:12:16ID:???0635621
2008/11/15(土) 01:03:38ID:???うーん・・ダメっぽいです。
とりあえず今回は時間もないので1.1で作ることにします。
いろいろとありがとうございます。
0636nobodyさん
2008/11/15(土) 02:07:44ID:???0637nobodyさん
2008/11/15(土) 02:18:29ID:???例えそれがフレームワーク側のバグだとしても。
過去に経験があったのは文字コードの違いで真っ白になると言う事はあった。
コードに複数の文字コード混じったりしてない？
それ以外はページ上なりapacheログなりにエラー出てたが・・・。
0638nobodyさん
2008/11/15(土) 02:19:34ID:???どこで止まってるか突き止めるのは可能だね
0639nobodyさん
2008/11/15(土) 08:21:24ID:???表示が出なければApacheの設定の問題
出たらコメントアウトを１行ずつ外してデバッグメッセージ出して試していく
0640621
2008/11/15(土) 11:24:41ID:???>>636-639
みなさんありがとうございます。
アドバイスしてくださったようにいろいろ試してみました。
webroot上のファイルがきちんと拾えました。
ということで、mod_rewriteの設定がおかしいようではないようです。
で、現状わかったのは、とりあえず処理としてはdispacher.phpを
読み込むところまでは来ていることがわかりました。
（bootstrap.phpの最後まで）
もうちょっと調べてみます。
ここまで来たら動かしたい。
0641nobodyさん
2008/11/15(土) 18:45:37ID:???頭文字とった略語ってあるじゃん
PHP、ＤＢ、ＦＷなんてのもそうだけど
そういうのに複数形つけるのに抵抗感があるんだけど、普通なこと？
0642nobodyさん
2008/11/15(土) 19:01:10ID:???bbsなら一目だけどbbsesじゃ一瞬分からないから
やりたくないんだよなあああ
0643nobodyさん
2008/11/15(土) 19:03:19ID:???テーブル名bbsesだとモデル名bbse
テーブル名bbsだとモデル名bb
テーブル名bbssだとモデル名bbss
だめじゃんｗｗｗｗ
0644nobodyさん
2008/11/15(土) 19:10:27ID:???BBSをモデルにする設計が問題じゃね?
BoardとかThreadとかEntryとかにすればいいんじゃないか?
0645nobodyさん
2008/11/15(土) 19:12:01ID:???非略語にしないとダメっぽ
本当にこんなことしなきゃいけないのか・・・
中途半端に略語でも最後がs以外なら大丈夫なのが困る
英単語って全部非略語にしたらすっごい分かりにくくなると思うし
0646nobodyさん
2008/11/15(土) 19:14:29ID:???略語にされてる英単語に規則なんて無い
ただ長いものは略語にされてそれが広まってる
ＢＢＳの件はboardでもギリギリ分かるしそうするつもりだけど
他にもいくらでも略語はあるんだよね
CDでもDVDでも、ISBNでもISDNでもADSLでも
それらを非略語にする事に強い抵抗感があるんだがｗ
0647nobodyさん
2008/11/15(土) 19:19:38ID:???AS,BS,CS,DS,ES,FS,GS,HS,,,,,,,,,,,,
いくらでもsで終わる略語があるんだが
0648nobodyさん
2008/11/15(土) 19:20:51ID:???0649nobodyさん
2008/11/15(土) 19:25:32ID:???http://www.cpa-lab.com/tech2/inflects/
bbses,bbs,bbss全てモデル名がおかしなことになる
aases,aas,aassでも同じだから
0650nobodyさん
2008/11/15(土) 20:51:02ID:???そもそも命名規約がおかしいっての
0651nobodyさん
2008/11/15(土) 20:52:05ID:???どちらもNewsのまま
■ このスレッドは過去ログ倉庫に格納されています