私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレ【PHP】フレームワーク CakePHP 12ホール目【笑】
php スレッド一覧へ / php とは? / 携帯版 / dat(gz)で取得 / トップメニューみんなの評価 :
レスフィルター : (試験中)
使ったことないけど、これで解決できそう
http://d.hatena.ne.jp/basuke/20110908/1315479931
http://d.hatena.ne.jp/basuke/20110908/1315479931
cakeは良くも悪くもPHPらしいフレームワークということで配列主義なんじゃなかったっけ
>>604
basuke氏って今PHPやってるんだ。昔からのMacユーザーならﾉﾒﾓバスターには世話になったはず
basuke氏って今PHPやってるんだ。昔からのMacユーザーならﾉﾒﾓバスターには世話になったはず
CakePHPの悪い点
ユーザーが少ない
昔は多かったのかな、2009年あたりのブログ記事はいっぱい引っかかるね
ユーザーが少ない
昔は多かったのかな、2009年あたりのブログ記事はいっぱい引っかかるね
みんな配列きらいなんだな。逆におれは配列が扱いやすくてCakeから離れられん。
結局、どこでどういう配列を扱っているか覚えないといけないからな
オブジェクト指向に慣れると面倒臭いだろ
オブジェクト指向に慣れると面倒臭いだろ
えーぜんぜん違う。
オブジェクトのほうが柔軟に対応できるし、DRYにしやすい。
まあ結局は好みなのか。
オブジェクトのほうが柔軟に対応できるし、DRYにしやすい。
まあ結局は好みなのか。
みなさん管理画面ってどうやって作ってます？
一つ一つコードを書いていくのか、プラグインなど利用しているのか。
一つ一つコードを書いていくのか、プラグインなど利用しているのか。
appを分けるってことは、CakePHPのappディレクトリを複数持つということですか？
ほー。そいや、俺もsymfonyでは複数のapp作って管理画面と分けてたわ。よーするにフロントコントローラをもひとつって事な。
すっかりCakePHPの流儀に染まって忘れてた。
すっかりCakePHPの流儀に染まって忘れてた。
Railsでいうオブジェクト指向の認識なんだけど、
同じデータベースのテーブルを扱うにしても
そのテーブルにあえて違うオブジェクト名を用途別につけてあげて、
それぞれの用途でそのオブジェクト(テーブル)を操作していく。
そんな認識であってるのかな？
同じデータベースのテーブルを扱うにしても
そのテーブルにあえて違うオブジェクト名を用途別につけてあげて、
それぞれの用途でそのオブジェクト(テーブル)を操作していく。
そんな認識であってるのかな？
オブジェクトとして考えるなら、テーブルの事は一旦忘れた方がいいべ
別に、RDBのテーブルだけじゃなくて、LDAPのデータを取りに行く（っつーか、
データを保持っつーかアクセスする）もんもオブジェクトとして考えられるし、
アクセスする方法があるのなら、ブックマークにアクセスしてオブジェクトとして扱うブックマークオブジェクトも考えられる。
たまたま、RDBのテーブルの内容が、オブジェクトとして扱えるだけ、ってーことなんよ
（まぁ、「たまたま」じゃなくて、そういう風に設計してるからなんだけどな）
別に、RDBのテーブルだけじゃなくて、LDAPのデータを取りに行く（っつーか、
データを保持っつーかアクセスする）もんもオブジェクトとして考えられるし、
アクセスする方法があるのなら、ブックマークにアクセスしてオブジェクトとして扱うブックマークオブジェクトも考えられる。
たまたま、RDBのテーブルの内容が、オブジェクトとして扱えるだけ、ってーことなんよ
（まぁ、「たまたま」じゃなくて、そういう風に設計してるからなんだけどな）
肝心なとこ忘れた
>そのテーブルにあえて違うオブジェクト名を用途別につけてあげて、
>それぞれの用途でそのオブジェクト(テーブル)を操作していく。
同じテーブルでも、抽出の仕方や、扱い方で別物として分けた方が分かりやすい、という場合に違う名前のオブジェクトになる、ってーことで、「あえて」じゃないかな
例えば、ユーザーテーブルを、パスワードとの照合も合わせた機能を認証Objectとして扱う場合、とか。
>そのテーブルにあえて違うオブジェクト名を用途別につけてあげて、
>それぞれの用途でそのオブジェクト(テーブル)を操作していく。
同じテーブルでも、抽出の仕方や、扱い方で別物として分けた方が分かりやすい、という場合に違う名前のオブジェクトになる、ってーことで、「あえて」じゃないかな
例えば、ユーザーテーブルを、パスワードとの照合も合わせた機能を認証Objectとして扱う場合、とか。
ヘルパー使ってて思うんだけど、
本来、ヘルパーの使用ってコントローラーでやるべきじゃね？
出来るためビューにPHPのコード書かないのが望ましい気がする。
本来、ヘルパーの使用ってコントローラーでやるべきじゃね？
出来るためビューにPHPのコード書かないのが望ましい気がする。
どのヘルパーによるか？もあるんだが、確かにヘルパーに寄せるべきでない機能なんじゃないか？というのはある。
だが、例えばHTMLとして出力するときと、CSVとして出力する時はエスケープの仕方が違うので、最低限そういった処理をヘルパーとしてviewでしているのは正しい。
だが、例えばHTMLとして出力するときと、CSVとして出力する時はエスケープの仕方が違うので、最低限そういった処理をヘルパーとしてviewでしているのは正しい。
例えばビューで
if ($data['User']['status'] == 1) {
echo '公開';
}
みたいな書き方するけど、こういうのってビューで書くのおかしいと思う。
if ($data['User']['status'] == 1) {
echo '公開';
}
みたいな書き方するけど、こういうのってビューで書くのおかしいと思う。
ビュー側は
<? echo $model->getStatus(); ?>
みたいにしたい。
getStatusの中で分岐。
<? echo $model->getStatus(); ?>
みたいにしたい。
getStatusの中で分岐。
よくわらかんが、たとえばlayouts/default.ctpのビューで
<?php if (!$this->Session->check('Auth.User')): ?>
<a href="<?php echo Router::url('/users/register'); ?>">新規登録</a>
<?php endif; ?>
こういうのもあなた的にはおかしいんですか？
<?php if (!$this->Session->check('Auth.User')): ?>
<a href="<?php echo Router::url('/users/register'); ?>">新規登録</a>
<?php endif; ?>
こういうのもあなた的にはおかしいんですか？
ビューを「デザインする場所」だと思えばおかしいかも知れんけど、
「表示を司るプログラムを書く場所」だと思えばいいんじゃないの
>>631
elementからrequestActionを投げるのがそれに近いのでは。
「表示を司るプログラムを書く場所」だと思えばいいんじゃないの
>>631
elementからrequestActionを投げるのがそれに近いのでは。
632のようにビューで分岐させるのは、ありだと思う
ケースバイケースだけど
これは、デザイナーよりの分岐なので
デザイナーに編集してもらった方が楽
これくらいの分岐条件ならデザイナーでも、わかると思う。
これを関数で処理するとなれば、HTMLタグを関数内に入れる事になる
要は新規登録のリンクをヘルパーとして扱うのは、効率的に悪い。
新規登録のリンクは、関数として何度も使うことが無い。
新規登録、会員登録の分岐は、それ用にビューをつくっておいて
メインのビューから読み込ませればよい
ケースバイケースだけど
これは、デザイナーよりの分岐なので
デザイナーに編集してもらった方が楽
これくらいの分岐条件ならデザイナーでも、わかると思う。
これを関数で処理するとなれば、HTMLタグを関数内に入れる事になる
要は新規登録のリンクをヘルパーとして扱うのは、効率的に悪い。
新規登録のリンクは、関数として何度も使うことが無い。
新規登録、会員登録の分岐は、それ用にビューをつくっておいて
メインのビューから読み込ませればよい
俺的にはビューはデザイナに任せるから、PHPのコードが書いてあるなんてありえんのだが
みんなよくやるね
みんなよくやるね
というかデザイナーが仕上げた後にphpコードをプログラマが埋め込む。
phpコードを埋め込んだビューにデザイナが手を付けることはない。
デザイン出来上がり
↓
プログラム組み込み
phpコードを埋め込んだビューにデザイナが手を付けることはない。
デザイン出来上がり
↓
プログラム組み込み
ちょっとしたデータをphpの配列に書いてあってincludeして使いたい場合、どのフォルダに置く？
俺は「common」ってフォルダ作って、その中にファイル置いてる。
で、bootstrap.phpでincludeしている。
この方が自分が見た目でも分かりやすし、管理しやすいよ。
で、bootstrap.phpでincludeしている。
この方が自分が見た目でも分かりやすし、管理しやすいよ。
vendorsフォルダに入れて、使いたいときにApp::importするとか
>>643
Configureクラスに、必要に応じて設定を読み込ませられるメソッドがあった、ってーこと。なんだったかな。。。
そいつを使うと、確かconfigフォルダにファイルを置いておけば、ファイル名渡してやると必要に応じて読み込めたよーな。
Configureクラスに、必要に応じて設定を読み込ませられるメソッドがあった、ってーこと。なんだったかな。。。
そいつを使うと、確かconfigフォルダにファイルを置いておけば、ファイル名渡してやると必要に応じて読み込めたよーな。
設計について相談です。
mypageというコントローラーがあって、
日記の表示なら/mypage/diary_list、編集なら/mypage/diary_edit
というアクションにしているのですが、
これをするとmypage_controller.phpのソースが長くなります。
皆さんはどうしていますか？diary_controller.phpを作って
そこでindexとかeditのアクションを作っていくパターンでしょうか？
mypageというコントローラーがあって、
日記の表示なら/mypage/diary_list、編集なら/mypage/diary_edit
というアクションにしているのですが、
これをするとmypage_controller.phpのソースが長くなります。
皆さんはどうしていますか？diary_controller.phpを作って
そこでindexとかeditのアクションを作っていくパターンでしょうか？
>>647
mypageとdiaryのテーブル構造ってどうなってます？
mypageとdiaryのテーブル構造ってどうなってます？
質問です
言語というフォルダがあるとして
1.Japanese
2.English
3.Spanish
4.Chinese
とレコードがあるとしたら
リレーションキーとなるフィールドは別途数字フィールドを用意したほうがいいですか？
それとも
JAN
ENG
ESP
CHN
のように省略系の入った文字列フィールドで繋ぐのはありですか？
後者のほうが頭に入れておきやすいのですが
言語というフォルダがあるとして
1.Japanese
2.English
3.Spanish
4.Chinese
とレコードがあるとしたら
リレーションキーとなるフィールドは別途数字フィールドを用意したほうがいいですか？
それとも
JAN
ENG
ESP
CHN
のように省略系の入った文字列フィールドで繋ぐのはありですか？
後者のほうが頭に入れておきやすいのですが
前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ
/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで / 
php スレッド一覧へ類似してるかもしれないスレッド
- 【PHP】フレームワーク CakePHP 17ホール目【v3α】 (955) - [92%] - 2016/11/15 20:45
- 【PHP】フレームワーク CakePHP 14ホール目【v2.1】 (1001) - [92%] - 2012/12/3 19:16
- 【PHP】フレームワーク CakePHP 19ホール目【v3.3】 (844) - [92%] - 2023/2/2 14:30
- 【PHP】フレームワーク CakePHP 16ホール目【v2.4】 (1001) - [92%] - 2014/3/3 3:00
- 【PHP】フレームワーク CakePHP 11ホール目【v1.3】 (1001) - [92%] - 2011/6/30 22:32
- 【PHP】フレームワーク CakePHP 15ホール目【v2.2】 (985) - [92%] - 2013/9/7 8:30
- 【PHP】フレームワーク CakePHP 17ホール目【v2.4】 (984) - [92%] - 2015/1/10 2:45
- 【PHP】フレームワーク CakePHP 10ホール目【v1.3】 (1001) - [92%] - 2011/2/13 8:32
- 【PHP】フレームワーク CakePHP 13ホール目【v2.0】 (995) - [92%] - 2012/4/23 21:16 ○
- 【PHP】フレームワーク CakePHP 8ホール目【1.3】 (1001) - [91%] - 2010/7/22 22:16
- 【PHP】フレームワーク CakePHP 9ホール目【v1.3】 (1001) - [90%] - 2010/11/1 2:53
- 【PHP】フレームワーク CakePHP 3ホール目【本命】 (1001) - [87%] - 2008/6/19 7:19 ○
- 【PHP】フレームワーク CakePHP 6ホール目【v1.2】 (933) - [87%] - 2009/8/19 2:06 ○
- 【PHP】フレームワーク CakePHP 5ホール目【v1.2】 (985) - [87%] - 2009/3/7 4:53 ☆
- 【PHP】フレームワーク CakePHP 7ホール目【v1.2】 (1001) - [87%] - 2010/3/18 1:18 ○
トップメニューへ / →のくす牧場書庫について