元スレ【PHP】フレームワーク CakePHP　4ホール目【v1.2】

php覧 / PC版 /

みんなの評価 : ○

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ

/ 要望・削除依頼は掲示板へ / 管理情報はtwitterで

651 = :

ちなみにNewsは正しく使える
どちらもNewsのまま

652 = :

>>650
何が言いたいの？

653 = :

全部明示的にテーブル指定すればいいじゃん

654 = :

命名規約にルール追加は可能だけど
でもそれ本来は多言語対応や既存テーブルのためでしょ
新規テーブルで正しい英語の複数形つけて対応出来ないケースがあるのはおかしい

655 = :

最初の質問者じゃないけど・・

よく
foreach ($posts as $post) {
echo $post['Post']['title]
......

みたいのが出てくるけど、
BBSとかNEWSの場合はどうしてる？

無理やり
foreach ($newses as $news) {
......
とするのか、それとも
foreach ($news as $entry) {
......
みたいにするのか・・・

656 = :

そもそも、略語の複数形って一般的な英語にあるのか?
例が思いつかないのだが。

657 = :

CDs、OSsなんかは見かける。
一般的な英語では略語は普通大文字だが、
cakephpではテーブル名は全て小文字にしなきゃいけないからさあ大変

659 = :

>>652
データベースにシステムを格納するかってことだろ？
格納するのはboardの情報とboardに書かれた記事(contentsやarticleみたいな)だろ
それを管理するシステムを総称してBBSになるんじゃないのか

660 = :

>>659
そんなのは問題じゃなくない？
ずれた事言ってるよね君

一般的に全ての場合において正しい設計をすれば
略語の複数形で困る事なんて無い、って言えるなら別だけどｗ

661 = :

>>657
cd_infomations
os_informations
格納するのはCDやOS自体ではなくそれに関する情報だろ

662 = :

>>661
頭悪い奴は黙ってろ
usersをuser_informationsとすべき理由なんて無い
cdやosの複数形に困るから苦し紛れでつけるに過ぎないだろ
情報機器であるサーバマシンのＤＢに入っているものが情報である事なんて明示する必要が無さ過ぎる

663 :

実装に困らない回避例出してくれてるのに、
英語原理主義にこだわってかみついてる奴ってなんなの？

664 = :

>>662
命名規約はフレームワークに合わせてねってだけのこと
嫌ならフレームワーク使うな

665 = :

あくまで苦し紛れの回避策でしかないのに
それがあたかも回避策ですら無くすべての命名はこう行うべきだというニュアンスで言ってるからだろ

667 = :

ものすごい曲解ですね

668 = :

_informationsとつけるのは回避策であって
＞格納するのはCDやOS自体ではなくそれに関する情報だろ
この様に一般的な解釈のもと行う事じゃない

こんな苦肉の策をとらなきゃいけないのかという話なのに
さも当然の事のようにこんな事主張されてもｗ

669 = :

それがフレームワークの制約という奴です
嫌ならCakeやRoRの使用はお控えください

670 = :

実際問題開発の現場でも、フレームワークのここが自由にできないって
開発止める奴いるから仕方ないよ。

671 = :

別にこの回避策は既にやってるし良いんだが
これが一般的な解釈のもとやる事だと言われたら納得できるわけないだろｗｗｗ
しかも数レス引っ張って何かすごい意見を持ってるのかと聞き出したらこれじゃあなｗ

672 = :

そうなんだ
そこまでDBの名前に拘るのって
神経質ではないの？

DBの名前の不自由さ>cakeを使うこと
って単純な話なの？？

673 = :

いやお前の方が曲解だろｗｗｗｗ
そんな気になるならせいぜい１００万回でも俺の文章読み直してろ低脳

674 = :

ｗを２個以上使った時点で議論は負けだ

675 = :

これを議論と捕らえてるのがおかしい
相手は何も主張してないし、俺はそいつがどれ程頭の悪い考え方をしてるのかを親切で教えてやりたいだけだからなｗｗ

676 = :

会ったら良い人なのに…(たぶん

677 = :

実際あったら>>670の部下だったとか

678 = :

命名の話題になっているので、聞きたいのですが、
watchlistとかguestbookのような場合、テーブル名は
やはり複数形にするのでしょうか？
ウォッチリストやゲストブックが複数あるわけではないので、
ちょっと違和感があるのですが・・・

それとも、上で話されていたように、
guestbook_entriesのようにするのが妥当でしょうか？

679 = :

どっちでもいいと思うが

681 = :

>>678
guestbook_をつけるかどうかは他モデルとのかぶり具合によるけど
entriesのようにするのが、適切でしょうな

foreach ($entries as $entry) ... みたいな

682 = :

ER図の作成ソフトどうしてる？
cakeの規約に揃うように設定できるものがみつからない

683 = :

ちなみにforeachの右側の命名は一律で良いと思います
変数はforeach宣言したときに初期化されるし
わざわざ命名する時間は省ける

foreach ($entries as $line)

foreach ($entries as $k => $v)

684 = :

まあそれでいいかもね
コード見る時はforeach見た時点で配列の順次処理なんだと分かるし

685 = :

2重以上のループの時は辛い
$v2とかすればいいのかもしれんが、階層に依存した名前は付けたくないな。

686 = :

関数化できそうだな
各階層用のコールバック関数の配列を引数に取って順次処理するような
内部では自分を再帰的に呼び出すようにしておけばforeach自体は一つで済む

687 = :

それは気持ち悪いというか美しくないとうか。
それにforeach外のローカル変数にアクセスできなくなるし。
手間という意味では本末転倒。

688 = :

foreachの中が長くなるようならちゃんと名前をつける。

コードを読むときに、foreachを含めて一塊で読むか
foreachの中だけを読むか。

短いコードならforeachも含めて一塊にして読むが
長ければ、ループする処理ってのはおいといて、
中身だけを取り出して読む。

塊の中で名前が適当でもわかるなら（つまり前者）省略してもいいが、
塊の中でいきなり$vとか出てきてもわからないだろう？（つまり後者）って
時はちゃんと名前をつける。

689 = :

そういや、ちょっと前にfindの話でメソッドをまとめるのがよいって話あったけど、
クラスのプロパティに代入するメソッドを作る場合、

setPramA($data);
setPramB($data);

とプロパティごとに作るより、

set('paramname',$data);

として一カ所にまとめたほうが幸せなんすか？

692 = :

すみませんが、質問です。

cake bake で自動生成されるコードのインデントを、TABではなくて半角スペー
ス4つにしたいのですが、それを設定する方法があったら教えていただけないで
しょうか？

693 = :

>>692
scaffoldなら
cake/libs/view/scaffolds のファイルを書き換えたら良かったはず

bake も利用しているかもよ

695 = :

>>633-694
ありがとうございます。自分でももっと調べてみます。

697 = :

CakePHPのデフォルトってSHA256だろ？
だったら複合化は無理だろ
可逆暗号に変える必要があるが、セキュリティを落としてまで複合化する必要性ってなんだ？

699 = :

すみません、細かい質問なのですが、
controller.php のソースで、
$this->{$this->modelClass}
という記述がよく見つかります。

これは何をしているのでしょう？

そもそも、$this->{何か} という記述がどのような動作になるのか、わかりま
せん。教えていただけないでしょうか？

700 = :

ちょっと補足します。
$this->プロパティ名なら、どういう動作かはもちろんわかります。
$this->{何か評価される式} というのが、どういう振る舞いをするのかわから
ないのです。

ためしにこんなことをしてみましたが、エラーになりました。
$x = "hoge";
$this->{$x}; // エラー