【PHP】フレームワー� ..
479:nobodyさん
08/10/29 10:02:34
save関数でupdateするときカラム指定しないと
idとcreated以外の全カラムが更新されるよね？
俺はカラム指定で保存する場合はこうしてるよ
更新カラムが少ないときはこうするけど
$this->data['モデルA'] = array('name'=>'うんこ');
$this->モデルA->save($this->data, false, array('name'));
更新カラムが多いときはこうすると楽だよ
$this->data['モデルA'] = array('name'=>'うんこ','mail'=>'unko@unko.com');
$this->モデルA->save($this->data, false, array_keys($this->data['モデルA']));
480:nobodyさん
08/10/29 10:09:11
>>453
php初心者だと思うけど
なんか間違ってると思うよ。俺は
var $useTable = false;
でいけてるよ
481:nobodyさん
08/10/29 10:12:11
ＩＤＥ環境だけどCakePHP対応して欲しいと思うなら
eclipseで自分にあったプラグイン作ればいいよ
これほど自分にあったＩＤＥ環境はないよ
482:nobodyさん
08/10/29 15:09:41
ページング処理をしたく、
controllerに、$this-set('users',$this->paginate()); と書いたのですが、
Fatal error: Call to undefined method TasksController::paginate()
と、コントローラでエラーが出ます。
こうした場合、どこを調べれば良いでしょうか？
483:nobodyさん
08/10/29 15:23:33
>>482
○ $this-set
× $this->set
ここらへん？
484:482
08/10/29 15:32:02
>>483
cakephpの古いバージョンを使っていたせいでした; ごめんなさい
確かにそこも間違えてました;;
485:nobodyさん
08/10/29 16:28:20
submitiボタンに画像を使いたいのですが、formヘルパーのsubmitではできますか？
それともhtmlヘルパーのimageで工夫すればよいのでしょうか？
486:nobodyさん
08/10/29 17:50:53
>>485
submitのオプション又はsubmitImageで出来ますがマニュアルぐらいは読んどこう。
487:nobodyさん
08/10/29 18:45:53
>>486
謝謝
googleで調べまくっていたのですがなかったのですがマニュアルにありましたか。
もっとじっくり読めばよかったです。
488:nobodyさん
08/10/29 19:27:11
なんか文字小さくなっていたり、例が少ないのも一部あるけど
標準ヘルパー系はマニュアルにちゃんと書いてある
489:nobodyさん
08/10/30 20:56:23
何で1.2の日本語マニュアル
URLﾘﾝｸ(book.cakephp.org)
は、深い階層を開いていくと、右側が切れて
table of contentsが見えなくなるんだろう…
IEでもFirefoxでもいっしょ。
490:nobodyさん
08/10/30 21:17:18
>>489
特定のページのみ、右カラムのメニューになぜかまたヘッダー部分が出力されているから。
アプリのバグ。
491:nobodyさん
08/10/30 22:14:20
>>490
なるほど。バグすか。
読めなくて困るんですよね…
492:nobodyさん
08/10/31 18:02:22
スレチなんだけどさー
小さな会社の優秀な技術者の採り方 第0回を開催しました
URLﾘﾝｸ(techlife.cookpad.com)
この記事読んでどう思う？ 特に下のあたりについて。
＞入社しようと思った理由
＞ * やりたいことができる
＞ o 好き勝手やってよい文化がある
＞ o 経験が生きる
＞ o キャリアパス上重要なことが学べる
＞ * 環境がいい
＞ o 優秀な同僚
＞ o 海外の事業所がある
＞ o 女の子かわいい
＞ * 会社の将来性が感じられる
＞ o 世界で唯一のチャレンジを行っている
＞ o 目的がはっきりしている
＞ * 感じが良い
＞ o 採用プロセス上 で会ったのがとても良い人
＞ o 社長が面白い
＞ * 縁があった
＞ o 友達とか先輩とかが居た
＞ o バイトしてた
493:nobodyさん
08/10/31 20:21:19
>>492
ｽﾚ違い
494:nobodyさん
08/10/31 20:32:17
まーまーそー言わずにさー感想聞かせてくれよ－
頼むから次は、ｽﾚ違い、とか言わないでくれよー
495:nobodyさん
08/10/31 22:54:26
小学生からやり直せ
496:nobodyさん
08/11/01 00:18:12
わかっててスレチ投稿したんじゃないのかよ
497:nobodyさん
08/11/01 02:50:08
例えば商品レコードが
id、カテゴリid、値引率、……
みたいになってるとして、
カテゴリid（≒PK以外）を指定して
「該当するカテゴリの値引率を一括で10%に」
みたいな更新って、
（CAKEの機能として）可能ですか？
（Model->save()は
id指定して一件ずつ更新するしかないんだよね？）
498:nobodyさん
08/11/01 08:59:38
updateAll
499:nobodyさん
08/11/01 23:47:11
例えば...「顧客A,顧客B,顧客C,...と今後も顧客は増えるとして、
それぞれの顧客の取引情報をデータベースに入れるとする。
だけど、それぞれの顧客の情報を串刺しで集計する事は無い。」
という（まあ普通じゃない）状況があるとする。
CakePHPで使うデータベースとしてSQLiteを使って、
SQLiteとかならデータベース１つ＝1ファイルなので、
それぞれの顧客ごとにデータベースを分けて保存する事って、
できますか？つまり、動的に接続するデータベースを増やせるか？
って事なんですが。
本来なら、MySQLでもなんでも、一つのデータベースに入れて、
SQLのWHEREで抽出すれば済むじゃん、って言われそうだけど。
組み立てる条件が増えるとミスが増えそうなんで。
データベースを使わず、1顧客につき１つのテキストファイルに
入れるって案も有るんだけど。テキストファイルよりは、
一応SQLiteでもデータベースに入れた方が楽かな、と思ったので。
500:nobodyさん
08/11/02 00:12:07
CakePHPを使わない場合のやり方は分かるの？
501:nobodyさん
08/11/02 00:53:13
PHP5限定＆SQLite決め打ちなら、
function db($kokyaku){
sqlite_open($kokyaku);
...
}
ってするだけと思ってるんだけど。
502:nobodyさん
08/11/02 06:29:06
>>499
それはすでにデータベースとは呼べない気がする。
503:nobodyさん
08/11/02 10:58:34
普通じゃないのは認める。
でも、顧客一人一人のデータに関しては、
データベースって言えると思う。
例えば、顧客AのデータをノートPCに
移して持ち出したりする時に、
データベース全体を持ち出すのは危険だし、
その度にいちいちDUMPするのも無駄が多い
（と思う）
そこで、（例えば）SQLiteなら、その顧客の
データベースのファイルだけを持ち出すのが
簡単かな、と。思ったわけですが。
504:nobodyさん
08/11/02 11:04:28
>>499
>組み立てる条件が増えるとミスが増えそうなんで。
ここら辺から考え方がおかしくなっている気がするぞｗ
串刺しの集計はしなくても、IDをキーに単純抽出する為の場所という認識で
一つの顧客テーブルを使えばいいんじゃないのか？
505:nobodyさん
08/11/02 12:25:01
> 本来なら、MySQLでもなんでも、一つのデータベースに入れて、
> SQLのWHEREで抽出すれば済むじゃん、って言われそうだけど。
> 組み立てる条件が増えるとミスが増えそうなんで。
この理由でデータベース分けるくらいなら、RDB使わないほうがいいんじゃ‥
データベース単位じゃないけど、テーブル自動生成するやつならつくったことある
506:497
08/11/02 12:31:59
＞498
ありがと
1.2で追加されたのね……
手元の資料になかったお ＞＜
507:nobodyさん
08/11/02 14:52:56
>>505
うむ。RDBじゃなくていいんだ。
でも、CakePHPは使いたいんだ。
で、データの管理で楽したいんだ。
508:nobodyさん
08/11/02 15:11:53
検索とかしないんだったら
必要なデータをクラスにまとめて
保存・更新の際にシリアラズしてDBにぶちこめばいんじゃね
509:nobodyさん
08/11/02 17:41:13
個々の顧客データの中では検索したいんだな。
「顧客」って書くから漠然としていて分かりづらいんだな・・・
「辞典」って読み替えてみて。「顧客A」は「国語辞典」、「顧客B」は「カタカナ語辞典」
と、目的毎に辞典の種類は増えて行く。（辞書の場合、串刺し検索できると便利だけど）
全部のデータを一まとめにしたくない。辞書の種類毎にデータベースを分類したいんです。
で、その分類は、例えば「萌え用語辞書」が追加されるとか、どんどん増やして行きたい。
その度に、別のデータベースに分けたい。一つのデータベース、例えば「国語辞典」の中では、
もちろん検索できないと困る。ただし、用語の説明の中身は、用語によって様々だから、
シリアライズして放り込むつもり。
そうすると、SQLiteでデータベースを分けて作ると、１つのファイルがそのまま1冊の
辞書そのものになる。←今回は、ここが重要
これなら「カタカナ語辞書」のファイルを友達に渡しても、「萌え用語辞書」が雑じってる
ことは無いので安心。（例えば、ね）
そういう、いわば辞書編集システムを、CakePHPのデータベースを扱う部分の工夫で
なんとか簡単に作れないかなー、というところなんです。
CakePHPでも複数のデータベースは使えるけど、あらかじめ'database.php'に
書き込んだ物に限られる。これが、動的に増やしたり変更する方法があれば有り難い。
510:nobodyさん
08/11/02 17:49:09
動的に増やしたり変更したりすればいいじゃない
511:nobodyさん
08/11/02 21:34:39
>>510
できるの？
512:nobodyさん
08/11/02 21:47:23
逆にできない理由を知りたい
513:名無し募集中。。。
08/11/03 23:33:04 8PMDTqib
1.1から1.2にしてがんばってるんだけど、
左上に実行中のメソッド名が表示されちゃう(HTMLの最初にメソッド名が出力されている)
んだけどなぜなんだろうか。
514:nobodyさん
08/11/03 23:35:05
しまったお里が知れてしまった。
出ているのはメソッド名じゃなくてview名らしい。
515:nobodyさん
08/11/03 23:40:04
めっちゃ自己解決した
拾ってきたbeforeRender()のサンプルの中に
echo $this->action;があったよ死のう。
516:nobodyさん
08/11/04 00:02:52
この間わずか7分の出来事であった・・・
517:nobodyさん
08/11/04 05:42:03
>>515
死んだら・・・だぁめ♪
518:nobodyさん
08/11/04 12:59:24
死んだら・・・らめぇ
519:nobodyさん
08/11/06 21:23:56
すみませんが、質問です。
bakeについてですが、これはCakeの配置のされ方が、下のページの
URLﾘﾝｸ(book.cakephp.org)
Developmentであることを前提にファイルを生成するもので、Production や
Advanced の配置では使うことができない（現実的でない）という理解でよろし
いでしょうか？
520:nobodyさん
08/11/06 21:30:59
追伸。
もし、上の理解が間違っていて、Advancedの配置でもBakeが使えるのだとした
ら、Advancedの一例として、Cake のシステムは共通だが、作成するWEBアプリ
ケーションが同一サーバに複数あって、Cakeの同一のシステムを共有している
場合、特定のWebアプリをどうやってコード生成のターゲットとするか、その指
定方法を教えていただけたら、と思います。
521:nobodyさん
08/11/06 21:38:37
bakeで作ればコア（cakeフォルダ）へのパスは自動設定されているはずだからどこにおいても問題ない
522:nobodyさん
08/11/06 21:39:33
普通に日本語の方を見ればいいのでは
URLﾘﾝｸ(manual.cakephp.org)
駄目だとしても他の場所に作って移動すればいいのではないかと思うんだけど
それじゃ駄目なのかな？
まあ俺が>>513と同一人物と言うことは内緒だが
523:nobodyさん
08/11/06 22:00:26
>>521
すみません、ちょっとおっしゃる内容が分かりません。
少し詳しく質問し直させてください。
例えば、こういう配置だとします。
cake
/usr/lib/cake（個々のユーザは読み取り権限しか持たない）
app
/home/user01/app
/home/user02/app
...
webroot
/home/user01/htdocs
/home/user02/htdocs
...
webrootには各人ごとにindex.phpを置いて、cakeとappの位置を指定します。
この場合、/usr/lib/cake/console に個々のユーザが移動して、./cake bake
を実行した場合、例えばModelのファイルはどこに生成されるのでしょうか？
おそらく /usr/lib/cake/app/models だと思うのですが、ここには一般ユーザ
の書き込み権限がないので、動作しません。
個々のユーザごとに、/home/user0X/app/modelsに出力するよう bakeは指定で
きるのでしょうか？
524:nobodyさん
08/11/06 22:01:50
>>522
日本語のほうはURLが長いのでわずらわしいかと思いまして。
ひとつ前のレスに書きましたが、書き込み権限がない場合を想定しています。
525:nobodyさん
08/11/06 22:20:55
すみませんが、こちらの事情で、明日までここにアクセスできなくなりました。
質問させていただいたのに、非礼をお詫びいたします。
526:nobodyさん
08/11/07 01:23:09
>>523
Bakeでapp一式を生成する話かと思ってたが、modelとかを作る場合の話ね。
cake bake -app <appフルパス>で指定できる
または、
/home/user01/appをカレントディレクトリとして、cake bakeを実行すればよい。
但し、/usr/lib/cake/consoleにはパスを通しておくこと。(ちと気持ち悪いが)
527:nobodyさん
08/11/07 10:47:32
>>526
ありがとうございます！なるほど、コマンドラインオプションで指定するのか。
それにしてもbakeのドキュメントって見つからないと思ったら、
./cake bake help
こうすれば説明が読めることにやっと気づきました。
この説明以外にドキュメントがないというのが何ともですが。
後はソース読むしかないか。Railsもそうだったけど。
528:nobodyさん
08/11/07 13:57:45
いろいろ調べても出来なかったのでご教授願いたいのですが。
MySQLに画像は保存できるのですが、その画像をselectしてViewで表示するにはどうやればいいですか？
外部のPHPに記述して読み出すようにはあるのですが、cakePHPのViewから同様のことができません。
529:nobodyさん
08/11/07 14:03:58
>>528
何をやって、どう駄目だったのか書いたほうがいい。
外部のPHPなら、Cakeのviewで普通に画像として呼び出せばいいんじゃないの？
530:nobodyさん
08/11/07 14:13:15
>>529
$this->data['Event']['imagedata']にイメージのバイナリがセットされています。
echo $html->image($form->value('Event.imagedata'));
で表示させるとバイナリのまま表示されます。
それでimage.phpを作成して、header("Content-type:image/gif");を指定して
外部のPHPファイルで画像のバイナリを表示させようとしたのですが、
ビュー以下において単純な<img src="image.php">では呼び出せずにいます。
webroot以下やコントローラー以下にも配置したのですが同じでした。
ファイルの置き場所が悪いのでしょうか？
それとも簡単に出来る方法があればよろしくお願いします。
531:nobodyさん
08/11/07 14:51:26
>>530
イメージのバイナリを画像表示用のviewに渡して、viewでheader吐けばいけそうだけど。
MVCの設計としてどうかは知らん
最終的には画像表示用のコントローラ作ればいいんじゃないかな
532:nobodyさん
08/11/07 14:55:58
>>531
ビューでheaderをはきたいのですが他にもHTMLがありますので、画像の部分だけ「Content-type:image/gif」とかを指定したいのです・・・
533:nobodyさん
08/11/07 15:34:56
>>532
メディアビューを使えばできますよ。
マニュアルのビューの所。
534:nobodyさん
08/11/07 15:44:18
>>533
メディアビューは初めて聞きます。
サンプルはバイナリファイルをダウンロードさせるようになっていますね。
画像の場合はどのようにすればいいのかまだ分かりません。
例えばMySQLから取得した画像のバイナリーデータを
ＳＮＳのプロフィール画像のように表示させたいのです。。。
535:nobodyさん
08/11/07 16:06:14
なんかPHPをきちんとやらずに急にCake触ってる匂いが・・
>>532
そもそもHTMLと画像は別ファイルだよ。
外部のPHPファイルで画像表示に成功しているなら、viewに直接imgタグ書けばいいだけかと。
536:nobodyさん
08/11/07 16:12:29
ああ実物がないとメディアビューじゃダメか。失礼。
537:nobodyさん
08/11/07 16:12:54
beforeRenderでファイル吐いてexitしちゃえよｗ
538:nobodyさん
08/11/07 16:37:20
１．HTMLを表示
２．MySQLから取得した画像のバイナリをイメージで表示
３．HTMLを表示
上みたいな感じなので、２のパートだけをContent-type:image/jpegにしたいのですが
エレメントとかで分けてもheader("Content-type:image/jpeg");を記載したら
URLだけしか表示されないのです。
そのままだとバイナリデータが表示されます。。。
おとなしく画像をアップしてパス指定で管理するしかないのですかね。。。
539:nobodyさん
08/11/07 16:47:27
cakePHPを使用しないのであればビューからPHPを呼べばできそうなのですが・・・
URLﾘﾝｸ(q.hatena.ne.jp)
540:nobodyさん
08/11/07 17:31:48
>>538
>>535に書いたとおり、一つのファイルでHTMLと画像を兼ねるのは無理だよ？
541:nobodyさん
08/11/07 17:40:49
画像をHTMLにアスキーデータで組み込むのは無理じゃないよ
542:nobodyさん
08/11/07 17:53:54
>>541
今回はそういう事を意図してない雰囲気はする
543:nobodyさん
08/11/07 18:13:58
>>542
ご回答ありがとうございます。なかなか難しいのですね。
cakePHPでSNSのプロフィール画像を表示させたいイメージなのです。
ファイルをアップしてリンクのテキストで対応するのは出来るのですが、
バイナリーで保存してやりたいということです。
544:nobodyさん
08/11/07 18:32:58
>>543
あなたには無理ですのであきらめてください。
545:nobodyさん
08/11/07 19:05:29
>>544
つまんねぇレスすんなハゲ
これは使えないかな？
サムネイルコンポーネント
URLﾘﾝｸ(www.hideblog.net)
もっとスマートにできるなら俺も知りたい。
546:nobodyさん
08/11/07 20:24:31
ビューでバイナリを吐けるんだったら、レイアウトを空にして、ヘッダー付ければ出来ない？
文字データなら出来たけど。
547:nobodyさん
08/11/07 21:14:59
Railsなら簡単に出来たけど、Cakeだと難しいのかな。
548:nobodyさん
08/11/07 22:25:45
別件でお取り込み中のところすみませんが、質問です。
コントローラのファイルを、種類によっていくつかのサブディレクトリに分け
て配置することは出来るのでしょうか？
app/controllers/hoge/hoge0_controller.php
app/controllers/hoge/hoge1_controller.php
app/controllers/fuga/fuga0_controller.php
app/controllers/fuga/fuga1_controller.php
このように複数のサブディレクトリを作り、その中にコントローラを分けて納
めるようなイメージです。
また出来るとしたら、それらのコントローラにはどのようなURLでアクセスでき
るのでしょうか？
549:nobodyさん
08/11/07 22:48:44
>>548
URLﾘﾝｸ(book.cakephp.org)
550:nobodyさん
08/11/07 23:08:49
>>549
なるほど、ありがとうございます。bootstrap.phpの$controllerPathsですか。
CakePHPでコントローラーを複数のディレクトリに整理する方法 - yandodの日記
URLﾘﾝｸ(d.hatena.ne.jp)
> 分散したディレクトリ内でファイル名やクラス名が衝突すると面倒な事になる
> と思われますので接頭語を付けるなどして管理するのが良いかもしれません。
うーん。コントローラの名前空間は共通なのか。
URLのパス指定で、各ディレクトリを呼び分けるとか出来ないでしょうか？
551:nobodyさん
08/11/07 23:29:48
Base64エンコードしたデータ格納しといてMHTMLで表示しとけよｗｗｗ
552:nobodyさん
08/11/07 23:32:23
mysqlの中に画像を入れるのは馬鹿だろ
そもそもmysqlは画像データを格納するために作っていないから
画像はフォルダに入れて管理した方がいいと
mysql作者が語ってるのに。
そんな自分もかけだしのときはmysqlに画像データ入れてました
管理は楽だけどね。かなりの負荷がかかる。
Bakeとか使う人も素人くさいと思う。
553:nobodyさん
08/11/07 23:49:13
>>552
同意。mysqlじゃなく適当なフォルダに画像を突っ込んだ方がいいよ。
554:nobodyさん
08/11/08 00:12:16
>>550
URLﾘﾝｸ(book.cakephp.org)
Routes追加すればURL上は階層化されてるように見せることは出来るが、名前の衝突は回避できない。
コントローラ名にパス名も入れればユニークになって衝突回避出来なくもないが、色々面倒なことになる。
555:nobodyさん
08/11/08 00:14:48
Bake便利だと思うけどな。
使うのはスキーマ検証時くらいだけど。
556:nobodyさん
08/11/08 00:17:44
そもそもBakeの使い方がわからないという。
557:nobodyさん
08/11/08 00:19:20
>>552,553
case by caseだとおもうけど
DBでファイルのパス管理してたらそのファイルが消されてたりとか。
かといって参照頻度が高いときはDBに置きたくないしな
さすがにデザインとかで使うような画像は普通に置いとくけどさ
558:nobodyさん
08/11/08 01:37:22
>>557
DBに入れておいて、参照されたらキャッシュを作り、そのキャッシュを送信するって方法もあるらしい。
2回目以降は早いし、ファイルが消えても問題ない。
559:nobodyさん
08/11/08 02:27:53
たしかにDBにも入れといたほうがバックアップは楽そうだね
560:nobodyさん
08/11/08 02:50:18
>>558
それ考えた奴天才じゃね？
561:nobodyさん
08/11/08 03:22:53
Cakephpでキャッシュオンにして簡単に実現できそうだ
562:nobodyさん
08/11/08 07:55:27
ここ
画像もDBに格納して管理する －扱いがめんどうなLOB(ラージオブジェクト)は使わない方法も含め
URLﾘﾝｸ(neta.ywcafe.net)
563:nobodyさん
08/11/08 11:22:34
画像格納に強いＤＢならいいけど
mysqlは画像を格納するという目的で設計されてないからね
だから画像をＤＢに入れるのが悪いというのではなく
画像をmysqlに入れるということがナンセンス
564:nobodyさん
08/11/08 11:26:06
mysqlは高速が売りだからね
画像格納させたいならoracleとかの方が合理的だと思うよ
565:nobodyさん
08/11/08 11:33:20
画像表示のパフォーマンスを考えればLinuxファイルシステムが最強
ＤＢと連携させて管理するのが面倒だけど、そこまで面倒な管理とも思えない
画像はデータの一つだからＤＢ格納がよいという理念なら
htmlもcssも全部ＤＢに入れよということになる
566:nobodyさん
08/11/08 11:38:58
データはなんでもかんでもＤＢという流れの人は
ＤＢの持つ性能とバランスをどこまで考えてるの疑問に思う
567:nobodyさん
08/11/08 11:42:47
だからあくまでキャッシュ前提の話なんだろ
568:nobodyさん
08/11/08 12:05:42
URLﾘﾝｸ(dev.mysql.com)
通常の Web サーバセットアップを使用する場合は、画像をファイルとして格納する。
言い換えると、データベース内にはファイル参照のみを格納する。この主な理由は、
通常の Web サーバのほうがデータベースコンテンツと比較してファイルのキャッシュに優れているためである。
このため、ファイルを使用したほうがシステムの高速化を容易に図れる。
569:nobodyさん
08/11/08 12:09:44
ファイルシステムによるキャッシュ前提なら、DBをバックアップするだけでユー
ザのデータを一括管理できるというメリットしか存在しないと思うけどな。
Railsのときはそうやってて、非常に便利だった。
570:nobodyさん
08/11/08 14:24:18
>>554
> コントローラ名にパス名も入れればユニークになって衝突回避出来なくもないが、色々面倒なことになる。
了解です。ありがとうございます。
今回はbootstrap.phpの$controllerPathsでやって、名前の衝突についてはその
都度対処することにしようと思います。
571:nobodyさん
08/11/08 15:12:49
A hasMany B
B hasMany C
で
C belongsTo D
みたいなときのリレーションの貼り方が判らないんですが、
そもそも可能なんでしょうか？
（Aを基点にA～Dのテーブルからデータを取ってくる想定）
SQL直書きでは勿論可能ですが。
572:nobodyさん
08/11/08 15:56:39
>>571
そこまでしてリレーションに拘るのは返って
生産性を落とす可能性があるから
要はバランスですね
どこからＳＱＬｌ直書きにするかの線引きはね
573:nobodyさん
08/11/08 16:42:40
MYSQLだから画像は駄目と硬直的に反応するのは駄目だな
アクセス頻度やキャシュの実装、使い方や状況によって向いてる場合もあろう。
574:nobodyさん
08/11/08 17:08:34
画像を表示させるにはフォルダにアップして管理するのが確実みたいですね。
簡単に出来るのなら採用したかったのですが・・・
575:nobodyさん
08/11/08 18:47:57
個人情報が含まれる画像だとDBで管理するのが普通でしょ
履歴書の写真とか。
576:nobodyさん
08/11/08 18:54:20
ファイルシステムで管理するからと言って、直接見られるところに
置くわけでは無いと思うが。
認証チェック経由でファイルを返すのが普通でしょ。
577:nobodyさん
08/11/08 19:06:19
ファイルシステムで認証チェックしてファイル返す方法ってbasic認証のこと？
578:nobodyさん
08/11/08 19:11:50
画像格納の話だけど
ファイルパスのみＤＢに突っ込んで画像はファイルシステムから読み出すようにすりゃ良いんじゃないの？
画像データそのものをＤＢに突っ込む必要があるとしたら、
バイナリデータで検索する場合しかなくない？
579:578
08/11/08 19:15:44
他にもあるな。
例えばＤＢだとデータをまとめて暗号化するようなソリューションがある場合があるが
ファイルシステムに保存するとそういう枠組みから漏れてしまう
まあファイルシステムドライバで暗号化すれば良いだけなんだけど
ドライバ方式とＤＢ方式の差異はパフォーマンスくらいか
それも特定ディレクトリだけ暗号化するようにすれば良いだけか
580:nobodyさん
08/11/08 19:26:04
<?php
// 何かしらの認証チェック...
header("Content-type: ...");
...
readfile( 直接ブラウズできないパスの画像ファイル );
?>
な処理をimgのsrcに指定。
581:nobodyさん
08/11/08 19:32:38
ブラウザ⇔phpは話題にしてないと思うんだけど
php⇔hdd間での画像データのやり取りをどうするかって事だよね
582:nobodyさん
08/11/08 20:14:49
>>581
元は前者の話
相談者のスキルが異常に低かったのでなぜか後者の話に移った
583:nobodyさん
08/11/09 06:03:18
画像をＤＢで管理てのもファイルシステムで管理てのも
同じくらい面倒だ、ＤＢ画像管理が最高に楽じゃない限り
パフォーマンスのいいファイルシステムになる
584:nobodyさん
08/11/09 06:10:19
mysqlを画像に入れた場合のメリットが見えない。。。
585:nobodyさん
08/11/09 07:31:37
>>565
同感。
586:nobodyさん
08/11/09 13:38:34
>>565
> 画像はデータの一つだからＤＢ格納がよいという理念なら
> htmlもcssも全部ＤＢに入れよということになる
画像はM
htmlやcssはV
DBには入れませんが。。。
587:nobodyさん
08/11/09 13:55:11
ユーザの作ったデータ（日々変動する）と、開発者の作ったデータ（基本的に
リリース時で固定）は別物だと思うが。
前者をDBで一元管理できると便利だよ。
まあ抵抗のある人に無理強いするつもりはないし、個々人の自由だと思うけど。
自分はCakePHPでもこれがやれるならやりたいなあ。
何とか実現できないものか。
588:nobodyさん
08/11/09 14:11:02
スケールする/しない、管理できる規模/できない規模の話だからな。
条件があえば、DB管理で一元管理でも良いと思う。
この辺を思い出した。
URLﾘﾝｸ(neta.ywcafe.net)
URLﾘﾝｸ(blog.livedoor.jp)
589:nobodyさん
08/11/09 15:42:14
MovableTypeとかCSSやHTMLテンプレートDBに入ってるだろ
590:nobodyさん
08/11/09 15:47:24
>>586
ページ上に表示されるような画像はＶだよ
そしてページ上に表示されない画像ならＷＥＢシステムの中に入れておくべきものじゃない
画像でありながらＭになりうるのは、画像検索システムのようなものだけ
591:nobodyさん
08/11/09 15:48:39
例えば履歴書の画像データの話が出たけど
それをＷＥＢ上からログインして観覧するようなシステムがあるならＶ
一切使い道が無いならＷＥＢシステム外で保管しておくべきもの
無いと思うけどその画像で画像検索するならＭ
592:nobodyさん
08/11/09 23:20:30
>>590
検索対象じゃないとMになれないの？
↓そう読み取れなかったが
Wikipedia項目ﾘﾝｸ
593:nobodyさん
08/11/09 23:25:24
設計にこれが絶対正解ってのはないでしょ。
要件次第だと思うよ。
594:nobodyさん
08/11/11 09:18:04
Ｖというのはファイル形式そのもので
ファイルをバイナリーデータに変えたものがＭである
595:nobodyさん
08/11/11 09:55:03
>>594
バイナリとかそんなデータ表現は一切問題じゃない
596:nobodyさん
08/11/11 11:39:47
Mはデータを扱う仕組み
Vはデータを表示する仕組み
Cはデータを操作する仕組み
画像はデータなのでそのどれでもないと思うが
597:nobodyさん
08/11/11 11:48:43
「扱う」と「操作する」の日本語の違いがわからないっす
辞書には
> あつか・う〔あつかふ〕【扱う】
> 道具・機械などを、使ったり操作したりする。取り扱う。
ってあったっす
598:nobodyさん
08/11/11 12:46:42
Cは操作限定
Mはデータの出し入れや変換、型決めなど広範囲に扱える
599:nobodyさん
08/11/11 18:28:03
MとかVとかなにいうてんねんとおもったら、MVCのことだったのか
600:nobodyさん
08/11/11 18:41:57
SとMなら分るんだけどな
601:nobodyさん
08/11/12 01:29:19
画像の加工はモデルに突っ込むね
コントローラはモデルで引っ張ったデータをチェックしてビューに渡すだけだな
602:nobodyさん
08/11/12 09:05:32
再利用する頻度の少ない加工処理はコントローラに書いてるよ
モデルに書くと生産性が落ちる
なぜなら
再利用できるように関数化させるのが手間
再利用が２回程度ならコントローラ上でコピペが最短
603:nobodyさん
08/11/12 09:12:09
あとモデルが厚くなりすぎると
総体的にコード量が多くなる。
なぜなら
symfonyのように
ＭとＶのやりとりが直接出来ないから
Ｃに橋渡し的なコードを書かないといけない分
コード量が増える
symfonyのうような仕様なら
モデルをどんどん厚くすべきだが
CakePHPの場合は
モデルを厚くしすぎるのも
作業効率が落ちると思う
604:nobodyさん
08/11/12 17:43:12
URLﾘﾝｸ(book.cakephp.org)
ここ見るとfind系が全部find()に統合されたって書いてあるけど、
findAllByって使っちゃっていいの？
特に非推奨とは書いてないけど。
findByとfindAllByだと配列で条件指定する新しい形式が使えなくて
nullを並べる旧形式のままだから、条件指定方法が統一できなくて
ちょっと気持ち悪いんだけど…
新形式の条件指定に対応しないってことは、そのうちマジックメソッド自体が
消える予定なのかな。
調べてみたけど、日本語だとこれくらいしか記事がない
URLﾘﾝｸ(d.hatena.ne.jp)
605:nobodyさん
08/11/12 17:55:00
findByGoogle
606:nobodyさん
08/11/12 20:14:45
>>604
find系てfind()でほとんど出来ると思うので
最初から意味の無さそうな機能だなとは思ってた
したがってfind()で統一してる人ばかりだと思うんで
どうでもいいよ
607:nobodyさん
08/11/12 20:23:16
似たような処理を持つ関数をやたら増やすもんでは無いと思う。
可読性とコーディング量は改善されるけど。
いつも使わない関数だとすれば、単なる無駄
608:nobodyさん
08/11/12 20:32:06
CakePHPの良いところは
データのやりとりが配列思考なところなんだよね
というのはphp自体が壊れたオブジェクト指向だから
配列思考型のフレームワークはphpにはピッタリだと思う。
あと配列思考型は中小規模にも適してる
CakePHP自体が中小規模を対象として設計されてると思う
rubyは完成されたオブジェクト指向言語だから
rorのようなオブジェクト指向型でのデータのやりとりがマッチする
609:nobodyさん
08/11/12 20:36:33
>>603
> ＭとＶのやりとりが直接出来ないから
つーかやったらいかんだろｗ
MVCって何か知ってるか。
まあそんなにやりたきゃ、viewにmodelを渡せばいいだけ。
610:nobodyさん
08/11/12 21:16:40
>>609
viewにmodelを渡せばいいだけ
具体的にお願いします
611:nobodyさん
08/11/12 21:43:29
$this->set($this->Model)
612:nobodyさん
08/11/13 01:50:37
>>608
ルビリンのことかーーーーーーーーっ！！！
613:604
08/11/13 11:26:34
>>606-607
やっぱりfind()で統一の方向なのか…
AND検索はマジックメソッド使った方が書きやすいから好きだったんだけど。
今後はfind()で統一してみる。
614:nobodyさん
08/11/13 12:56:14
できるだけモデルに書いた方が
いいと思うんだけどなぁ・・・。
再利用するかしないかは別として。
まぁ、個人的な意見なのですが。
615:nobodyさん
08/11/13 16:20:24
理由も書いてくれないと賛も否も
616:nobodyさん
08/11/13 18:25:42
コントローラにごちゃごちゃ書くとユニットテストがしにくい
617:nobodyさん
08/11/13 20:23:44
CakePHP本家はモデルを厚くすべきと書いてあるけど
生産性を第一に考えると関数化してモデルに入れるよりも
コントローラ内で同じ構文を連続コピペした方が早い場合もあるんだよね。
例えば、納期がほとんどないという、追い込まれた状況なら
わざわざ関数化するのも時間がかかるじゃん、そういう意味もあるんだな
時間が限りなくあるなら、出来るだけ関数化してモデルに入れるのがベストだけどさ
618:nobodyさん
08/11/13 20:26:25
関数化させる手間をどうバランス取るかだと思うんだが・・・
619:nobodyさん
08/11/13 20:32:36
モデルを厚くするというのは、ある程度
CakePHPでの経験が無いと、いきなりは、逆に時間がかかり
重要である生産性が落ちると思う。
経験を積みながら、少しずつリファクタリングすてモデルを厚くしていく方法がベストかな
620:nobodyさん
08/11/13 22:47:32
先月からCakeさわり始めて、
コントローラーにコードを書きまくってたんだが、
徐々に慣れてきてからは、モデルを厚くする方が良さそうだなという感想。
621:nobodyさん
08/11/14 15:37:31
1.2RC3がうごかない、インストールしたディレクトリにアクセスしても画面が真っ白になっちゃう
って現象に陥った人っていらっしゃいますか？
ブラウザ？と思ったんですが、どのブラウザでも真っ白になっちゃいます。
1.1系で試したらうまくいくのに…。
mod_rewriteも有効、phpのバージョンもOK、パーミッションも変更済み。
.htaccessの内容も確認しましたが、1.1と1.2で同じでした。
同じ現象にぶち当たった方、いらっしゃったら教えてください＞＜
622:nobodyさん
08/11/14 15:43:57
設定もしくはコーディング失敗したら真っ白になるけど
623:nobodyさん
08/11/14 15:59:49
デバッグレベルあげろよ
624:621
08/11/14 16:23:40
>>622
うーん、落としてきたモノをそのまま展開してるだけなんですよね。
どっかで間違えたのか・・・
>>623
デバッグレベルは3にしてあります。
それでも真っ白なんです＞＜
625:nobodyさん
08/11/14 16:25:23
＞624
PHPかApacheのログ見れ。
多分、cakeの問題ではない。
626:621
08/11/14 16:46:03
>>625
ありがとうございます。
でも、それらしいエラーは見あたりませんでした。。
でもなんとなくサーバーっぽい気はします。
627:nobodyさん
08/11/14 17:34:28
Shift_JIS で保存してるとか？
628:nobodyさん
08/11/14 17:36:59
サーバーっぽいってなんだよｗ
エラー無いのに何も表示されないなら何も出力しない処理に成功してるって事だろ
629:621
08/11/14 18:29:19
>>627
確認したんですが、それもなさそうです。。
>>628
そうですねｗ
いや、設定かなぁと。RewriteBaseとか。
でも別のサーバでは特に追記しなくても普通に動くので、なんだろう、と。
630:nobodyさん
08/11/14 19:48:22
1.1 -> 1.2RC2 のときに同じ現象陥った。
結局訳が分からず、一念発起して、1.2で書き直したけど。
同じかなあ？
631:630
08/11/14 19:50:04
あ、ごめん。移行の話じゃないか。スマン
632:nobodyさん
08/11/14 19:51:34
config/database.phpで文字コード明示とか、どう？
633:nobodyさん
08/11/14 22:25:29
NetBeand 6.5RC2使ってみたんだが、デバッグ時のmod_rewriteって対応してないの？
Eclipse+XDebug、NetBeansでCake mod_rewite無し版だとちゃんと使えるんだが・・・
634:nobodyさん
08/11/15 00:12:16
NetBeandって何？
635:621
08/11/15 01:03:38
>>632
うーん・・ダメっぽいです。
とりあえず今回は時間もないので1.1で作ることにします。
いろいろとありがとうございます。
636:nobodyさん
08/11/15 02:07:44
そんなレベルでいいのか仕事だろ
637:nobodyさん
08/11/15 02:18:29
ＰＨＰで動いてるんだから何かしらエラーは出るはずじゃないの？
例えそれがフレームワーク側のバグだとしても。
過去に経験があったのは文字コードの違いで真っ白になると言う事はあった。
コードに複数の文字コード混じったりしてない？
それ以外はページ上なりapacheログなりにエラー出てたが・・・。
638:nobodyさん
08/11/15 02:19:34
最悪、フレームワークのコードにデバッグメッセージ入れて
どこで止まってるか突き止めるのは可能だね
639:nobodyさん
08/11/15 08:21:24
webrootのindex.phpをコメントアウトして、適当にphpinfoとか出してみたら？
表示が出なければApacheの設定の問題
出たらコメントアウトを１行ずつ外してデバッグメッセージ出して試していく
640:621
08/11/15 11:24:41
諦められなくていろいろといじっていましたｗ
>>636-639
みなさんありがとうございます。
アドバイスしてくださったようにいろいろ試してみました。
webroot上のファイルがきちんと拾えました。
ということで、mod_rewriteの設定がおかしいようではないようです。
で、現状わかったのは、とりあえず処理としてはdispacher.phpを
読み込むところまでは来ていることがわかりました。
（bootstrap.phpの最後まで）
もうちょっと調べてみます。
ここまで来たら動かしたい。
641:nobodyさん
08/11/15 18:45:37
テーブル名を複数形にしろ、っていうけど
頭文字とった略語ってあるじゃん
PHP、ＤＢ、ＦＷなんてのもそうだけど
そういうのに複数形つけるのに抵抗感があるんだけど、普通なこと？
642:nobodyさん
08/11/15 19:01:10
BBSをbbsesって書かないといけないんだよね？
bbsなら一目だけどbbsesじゃ一瞬分からないから
やりたくないんだよなあああ
643:nobodyさん
08/11/15 19:03:19
ちょｗ
テーブル名bbsesだとモデル名bbse
テーブル名bbsだとモデル名bb
テーブル名bbssだとモデル名bbss
だめじゃんｗｗｗｗ
644:nobodyさん
08/11/15 19:10:27
>>642
BBSをモデルにする設計が問題じゃね?
BoardとかThreadとかEntryとかにすればいいんじゃないか?
645:nobodyさん
08/11/15 19:12:01
略語で最後がsで終わるものは
非略語にしないとダメっぽ
本当にこんなことしなきゃいけないのか・・・
中途半端に略語でも最後がs以外なら大丈夫なのが困る
英単語って全部非略語にしたらすっごい分かりにくくなると思うし
646:nobodyさん
08/11/15 19:14:29
>>644
略語にされてる英単語に規則なんて無い
ただ長いものは略語にされてそれが広まってる
ＢＢＳの件はboardでもギリギリ分かるしそうするつもりだけど
他にもいくらでも略語はあるんだよね
CDでもDVDでも、ISBNでもISDNでもADSLでも
それらを非略語にする事に強い抵抗感があるんだがｗ
647:nobodyさん
08/11/15 19:19:38
OSを複数形にしてossなんて書いたらオープンソースかと思っちゃうな
AS,BS,CS,DS,ES,FS,GS,HS,,,,,,,,,,,,
いくらでもsで終わる略語があるんだが
648:nobodyさん
08/11/15 19:20:51
全て小文字と言う制約も手伝って最悪な事になってるなｗ
649:nobodyさん
08/11/15 19:25:32
略語じゃなくても末尾がsで終わる単語の複数形に正しく動作しない
URLﾘﾝｸ(www.cpa-lab.com)
bbses,bbs,bbss全てモデル名がおかしなことになる
aases,aas,aassでも同じだから
650:nobodyさん
08/11/15 20:51:02
どうでもいいがBBSのSってSystemのSだぞ
そもそも命名規約がおかしいっての
651:nobodyさん
08/11/15 20:52:05
ちなみにNewsは正しく使える
どちらもNewsのまま
652:nobodyさん
08/11/15 21:08:11
>>650
何が言いたいの？
653:nobodyさん
08/11/15 21:13:25
全部明示的にテーブル指定すればいいじゃん
654:nobodyさん
08/11/15 21:17:17
命名規約にルール追加は可能だけど
でもそれ本来は多言語対応や既存テーブルのためでしょ
新規テーブルで正しい英語の複数形つけて対応出来ないケースがあるのはおかしい
655:nobodyさん
08/11/15 21:23:48
最初の質問者じゃないけど・・
よく
foreach ($posts as $post) {
echo $post['Post']['title]
......
みたいのが出てくるけど、
BBSとかNEWSの場合はどうしてる？
無理やり
foreach ($newses as $news) {
......
とするのか、それとも
foreach ($news as $entry) {
......
みたいにするのか・・・
656:nobodyさん
08/11/15 21:34:41
そもそも、略語の複数形って一般的な英語にあるのか?
例が思いつかないのだが。
657:nobodyさん
08/11/15 22:01:06
CDs、OSsなんかは見かける。
一般的な英語では略語は普通大文字だが、
cakephpではテーブル名は全て小文字にしなきゃいけないからさあ大変
658:nobodyさん
08/11/15 22:02:35
単にテーブル名は大文字、ってすれば良かった気がするんだけどね
複数形部分のみ小文字で
CDs,OSs
PROGRAMMERs
WEBSITEs
これでよかったのに
659:nobodyさん
08/11/16 00:39:32
>>652
データベースにシステムを格納するかってことだろ？
格納するのはboardの情報とboardに書かれた記事(contentsやarticleみたいな)だろ
それを管理するシステムを総称してBBSになるんじゃないのか
660:nobodyさん
08/11/16 00:40:39
>>659
そんなのは問題じゃなくない？
ずれた事言ってるよね君
一般的に全ての場合において正しい設計をすれば
略語の複数形で困る事なんて無い、って言えるなら別だけどｗ
661:nobodyさん
08/11/16 00:40:50
>>657
cd_infomations
os_informations
格納するのはCDやOS自体ではなくそれに関する情報だろ
662:nobodyさん
08/11/16 00:43:43
>>661
頭悪い奴は黙ってろ
usersをuser_informationsとすべき理由なんて無い
cdやosの複数形に困るから苦し紛れでつけるに過ぎないだろ
情報機器であるサーバマシンのＤＢに入っているものが情報である事なんて明示する必要が無さ過ぎる
663:nobodyさん
08/11/16 00:45:51 l+j4XBOD
実装に困らない回避例出してくれてるのに、
英語原理主義にこだわってかみついてる奴ってなんなの？
664:nobodyさん
08/11/16 00:46:33
>>662
命名規約はフレームワークに合わせてねってだけのこと
嫌ならフレームワーク使うな
665:nobodyさん
08/11/16 00:47:15
あくまで苦し紛れの回避策でしかないのに
それがあたかも回避策ですら無くすべての命名はこう行うべきだというニュアンスで言ってるからだろ
666:nobodyさん
08/11/16 00:50:45
systemはＤＢに格納するものじゃないだの
全てのテーブルには末尾に_informationsをつけるべきだの（格納するのはそれ自体じゃなくて情報だもんね？ｗｗｗｗ）
電波過ぎるだろ
667:nobodyさん
08/11/16 01:00:21
ものすごい曲解ですね
668:nobodyさん
08/11/16 01:07:42
_informationsとつけるのは回避策であって
＞格納するのはCDやOS自体ではなくそれに関する情報だろ
この様に一般的な解釈のもと行う事じゃない
こんな苦肉の策をとらなきゃいけないのかという話なのに
さも当然の事のようにこんな事主張されてもｗ
669:nobodyさん
08/11/16 01:11:08
それがフレームワークの制約という奴です
嫌ならCakeやRoRの使用はお控えください
670:nobodyさん
08/11/16 01:14:58
実際問題開発の現場でも、フレームワークのここが自由にできないって
開発止める奴いるから仕方ないよ。
671:nobodyさん
08/11/16 01:16:59
別にこの回避策は既にやってるし良いんだが
これが一般的な解釈のもとやる事だと言われたら納得できるわけないだろｗｗｗ
しかも数レス引っ張って何かすごい意見を持ってるのかと聞き出したらこれじゃあなｗ
672:nobodyさん
08/11/16 01:18:41
そうなんだ
そこまでDBの名前に拘るのって
神経質ではないの？
DBの名前の不自由さ>cakeを使うこと
って単純な話なの？？
673:nobodyさん
08/11/16 01:21:00
いやお前の方が曲解だろｗｗｗｗ
そんな気になるならせいぜい１００万回でも俺の文章読み直してろ低脳
674:nobodyさん
08/11/16 01:25:27
ｗを２個以上使った時点で議論は負けだ
675:nobodyさん
08/11/16 01:28:52
これを議論と捕らえてるのがおかしい
相手は何も主張してないし、俺はそいつがどれ程頭の悪い考え方をしてるのかを親切で教えてやりたいだけだからなｗｗ
676:nobodyさん
08/11/16 01:29:31
会ったら良い人なのに…(たぶん
677:nobodyさん
08/11/16 01:31:37
実際あったら>>670の部下だったとか
678:nobodyさん
08/11/16 03:47:10
命名の話題になっているので、聞きたいのですが、
watchlistとかguestbookのような場合、テーブル名は
やはり複数形にするのでしょうか？
ウォッチリストやゲストブックが複数あるわけではないので、
ちょっと違和感があるのですが・・・
それとも、上で話されていたように、
guestbook_entriesのようにするのが妥当でしょうか？
679:nobodyさん
08/11/16 04:24:01
どっちでもいいと思うが
680:nobodyさん
08/11/16 14:59:56
ポインタ（Pointer）の配列・・・
ポインタのポインタの配列・・・
ポインタのポインタの配列の配列・・・
ポインタの配列のポインタの配列・・・
681:nobodyさん
08/11/17 10:02:05
>>678
guestbook_をつけるかどうかは他モデルとのかぶり具合によるけど
entriesのようにするのが、適切でしょうな
foreach ($entries as $entry) ... みたいな
682:nobodyさん
08/11/18 01:37:43
ER図の作成ソフトどうしてる？
cakeの規約に揃うように設定できるものがみつからない
683:nobodyさん
08/11/18 13:09:08
ちなみにforeachの右側の命名は一律で良いと思います
変数はforeach宣言したときに初期化されるし
わざわざ命名する時間は省ける
foreach ($entries as $line)
foreach ($entries as $k => $v)
684:nobodyさん
08/11/18 17:07:52
まあそれでいいかもね
コード見る時はforeach見た時点で配列の順次処理なんだと分かるし
685:nobodyさん
08/11/19 00:26:30
2重以上のループの時は辛い
$v2とかすればいいのかもしれんが、階層に依存した名前は付けたくないな。
686:nobodyさん
08/11/19 00:41:14
関数化できそうだな
各階層用のコールバック関数の配列を引数に取って順次処理するような
内部では自分を再帰的に呼び出すようにしておけばforeach自体は一つで済む
687:nobodyさん
08/11/19 01:22:24
それは気持ち悪いというか美しくないとうか。
それにforeach外のローカル変数にアクセスできなくなるし。
手間という意味では本末転倒。
688:nobodyさん
08/11/19 02:21:00
foreachの中が長くなるようならちゃんと名前をつける。
コードを読むときに、foreachを含めて一塊で読むか
foreachの中だけを読むか。
短いコードならforeachも含めて一塊にして読むが
長ければ、ループする処理ってのはおいといて、
中身だけを取り出して読む。
塊の中で名前が適当でもわかるなら（つまり前者）省略してもいいが、
塊の中でいきなり$vとか出てきてもわからないだろう？（つまり後者）って
時はちゃんと名前をつける。
次ページ最新レス表示スレッドの検索類似スレ一覧話題のニュースおまかせリスト▼オプションを表示暇つぶし2ch
5320日前に更新/182 KB
担当:undef