のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,926人
頁
昨日:no data人
頁
今日:人
頁
最近の注目
人気の最安値情報

    元スレ【PHP】フレームワーク CakePHP 12ホール目【笑】

    php覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

    601 = :

    そんなに大変じゃないと思う

    603 = :

    >>594
    symfonyやYiiなんかは基本オブジェクトなんだよな。
    やっぱりCakeは合わない。

    604 = :

    使ったことないけど、これで解決できそう
    http://d.hatena.ne.jp/basuke/20110908/1315479931

    605 = :

    >>604
    これ見ると、俺も”オレオレ”ではエンティティ方式で書いてた。
    けど、この書き方だと統一感無いので配列の方が良いと思って今に至る。
    人それぞれ好みがあるんだな。

    606 = :

    cakeは良くも悪くもPHPらしいフレームワークということで配列主義なんじゃなかったっけ

    607 = :

    >>604
    basuke氏って今PHPやってるんだ。昔からのMacユーザーならﾉﾒﾓバスターには世話になったはず

    608 = :

    CakePHPの悪い点
    ユーザーが少ない

    昔は多かったのかな、2009年あたりのブログ記事はいっぱい引っかかるね

    610 = :

    >>609
    日本のみでやってみろよ。明らかにCakeが一番だ

    611 = :

    つまりはそういうことだ。

    612 = :

    みんな配列きらいなんだな。逆におれは配列が扱いやすくてCakeから離れられん。

    613 = :

    結局、どこでどういう配列を扱っているか覚えないといけないからな
    オブジェクト指向に慣れると面倒臭いだろ

    614 = :

    そんなに大差ないと思うけどな

    615 = :

    えーぜんぜん違う。
    オブジェクトのほうが柔軟に対応できるし、DRYにしやすい。
    まあ結局は好みなのか。

    616 = :

    柔軟に対応できる分、規則性が無いよ。

    617 = :

    みなさん管理画面ってどうやって作ってます？
    一つ一つコードを書いていくのか、プラグインなど利用しているのか。

    618 = :

    専用の管理画面作ってるよ。appも分けて。

    620 = :

    >>618
    その手があったか
    ソッチの方がシンプルに実装できそうだな
    俺はわざわざprefixとか利用してadmin_indexみたいな形でやってたわ

    621 = :

    ほー。そいや、俺もsymfonyでは複数のapp作って管理画面と分けてたわ。よーするにフロントコントローラをもひとつって事な。
    すっかりCakePHPの流儀に染まって忘れてた。

    622 = :

    >>609
    Yiiって海外では人気なんだな
    なんで日本で流行らんのかわからん

    623 = :

    日本語の情報が少ないからでしょ

    624 = :

    Railsでいうオブジェクト指向の認識なんだけど、

    同じデータベースのテーブルを扱うにしても
    そのテーブルにあえて違うオブジェクト名を用途別につけてあげて、
    それぞれの用途でそのオブジェクト(テーブル)を操作していく。

    そんな認識であってるのかな？

    625 = :

    オブジェクトとして考えるなら、テーブルの事は一旦忘れた方がいいべ
    別に、RDBのテーブルだけじゃなくて、LDAPのデータを取りに行く（っつーか、
    データを保持っつーかアクセスする）もんもオブジェクトとして考えられるし、
    アクセスする方法があるのなら、ブックマークにアクセスしてオブジェクトとして扱うブックマークオブジェクトも考えられる。

    たまたま、RDBのテーブルの内容が、オブジェクトとして扱えるだけ、ってーことなんよ
    （まぁ、「たまたま」じゃなくて、そういう風に設計してるからなんだけどな）

    626 = :

    肝心なとこ忘れた

    >そのテーブルにあえて違うオブジェクト名を用途別につけてあげて、
    >それぞれの用途でそのオブジェクト(テーブル)を操作していく。
    同じテーブルでも、抽出の仕方や、扱い方で別物として分けた方が分かりやすい、という場合に違う名前のオブジェクトになる、ってーことで、「あえて」じゃないかな
    例えば、ユーザーテーブルを、パスワードとの照合も合わせた機能を認証Objectとして扱う場合、とか。

    627 = :

    ヘルパー使ってて思うんだけど、
    本来、ヘルパーの使用ってコントローラーでやるべきじゃね？
    出来るためビューにPHPのコード書かないのが望ましい気がする。

    628 = :

    誤字すまん
    出来るためビューに　→　出来るだけビューに

    629 = :

    どのヘルパーによるか？もあるんだが、確かにヘルパーに寄せるべきでない機能なんじゃないか？というのはある。
    だが、例えばHTMLとして出力するときと、CSVとして出力する時はエスケープの仕方が違うので、最低限そういった処理をヘルパーとしてviewでしているのは正しい。

    631 = :

    ビュー側は
    <? echo $model->getStatus(); ?>
    みたいにしたい。
    getStatusの中で分岐。

    632 = :

    よくわらかんが、たとえばlayouts/default.ctpのビューで

    <?php if (!$this->Session->check('Auth.User')): ?>
    <a href="<?php echo Router::url('/users/register'); ?>">新規登録</a>
    <?php endif; ?>

    こういうのもあなた的にはおかしいんですか？

    633 = :

    ビューを「デザインする場所」だと思えばおかしいかも知れんけど、
    「表示を司るプログラムを書く場所」だと思えばいいんじゃないの

    >>631
    elementからrequestActionを投げるのがそれに近いのでは。

    634 = :

    >>633
    そうすると、どう考えてもビューをデザイナーがいじる事は無理だよね。
    CMSでよくある、管理画面からテンプレート（ビュー）を編集とかも。

    635 = :

    632のようにビューで分岐させるのは、ありだと思う
    ケースバイケースだけど
    これは、デザイナーよりの分岐なので
    デザイナーに編集してもらった方が楽
    これくらいの分岐条件ならデザイナーでも、わかると思う。

    これを関数で処理するとなれば、HTMLタグを関数内に入れる事になる
    要は新規登録のリンクをヘルパーとして扱うのは、効率的に悪い。
    新規登録のリンクは、関数として何度も使うことが無い。

    新規登録、会員登録の分岐は、それ用にビューをつくっておいて
    メインのビューから読み込ませればよい

    636 = :

    たしかにケースバイケースだな。
    効率と保守性の問題。

    637 = :

    俺的にはビューはデザイナに任せるから、PHPのコードが書いてあるなんてありえんのだが
    みんなよくやるね

    638 = :

    というかデザイナーが仕上げた後にphpコードをプログラマが埋め込む。

    phpコードを埋め込んだビューにデザイナが手を付けることはない。

    デザイン出来上がり
    ↓
    プログラム組み込み

    639 = :

    自分で書いたSQL文をページネーションしたい場合どうしたらいい？

    641 = :

    Configureに読み込ませればいいんでね？

    642 = :

    ぶーつとらっぷ

    643 = :

    >>641
    configフォルダのこと？

    >>642
    bootstrapだと全ファイルにincludeされて重くならないかな
    気にするほどではない？ファイルサイズは100KBないぐらい

    646 = :

    >>643
    Configureクラスに、必要に応じて設定を読み込ませられるメソッドがあった、ってーこと。なんだったかな。。。
    そいつを使うと、確かconfigフォルダにファイルを置いておけば、ファイル名渡してやると必要に応じて読み込めたよーな。

    647 = :

    設計について相談です。
    mypageというコントローラーがあって、
    日記の表示なら/mypage/diary_list、編集なら/mypage/diary_edit
    というアクションにしているのですが、
    これをするとmypage_controller.phpのソースが長くなります。

    皆さんはどうしていますか？diary_controller.phpを作って
    そこでindexとかeditのアクションを作っていくパターンでしょうか？

    648 = :

    >>647
    mypageとdiaryのテーブル構造ってどうなってます？

    649 = :

    質問です

    言語というフォルダがあるとして

    1.Japanese
    2.English
    3.Spanish
    4.Chinese
    とレコードがあるとしたら

    リレーションキーとなるフィールドは別途数字フィールドを用意したほうがいいですか？

    それとも
    JAN
    ENG
    ESP
    CHN

    のように省略系の入った文字列フィールドで繋ぐのはありですか？
    後者のほうが頭に入れておきやすいのですが

    650 = :

    訂正。
    フォルダと書きましたが
    テーブルでした。


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / php一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド

    トップメニューへ / →のくす牧場書庫について