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

元スレ【PHP】フレームワーク CakePHP 17ホール目【v3α】

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

401 = :

パンくずとかMETAの内容をビューから設定するのって、ちょっと違和感ある。
かと言ってコントローラーで設定するのも悩む。

402 = :

>>401
構造だけコントローラーで渡して表示はビューでやればええやん

403 = :

ディスク容量の制限の無いオススメのサーバはどこですか？
海外サーバを希望です。

405 = :

>>404
そんな感じ
二階層までならコントローラー名とアクション名に準じたタイトルでパンくず作ってあげてもいいかも
それ以上の階層はdbなりconfigure使うしかないんじゃないかなー

>>403
AWSっていう海外サーバーならお金払えば払っただけ無制限にディスク使わしてくれるらしいよ

406 = :

>>405
404だけど、やっぱりそうか。ページ名をどこで管理するかが問題なんだよなぁ。
DB使うと、簡単なページを追加した時でも、DBに追加する必要もあるし。

407 = :

Cake3のお勉強でもしようと思ったんだけど
インストールするのにComposerとかみんな使ってんの？
色々知らないことが増えてる…

408 = :

cake2で構築してるシステムを今さら3にアップするのは
やっぱりリスキーだよね？

409 = :

趣味なら良いと思うが、運用中で、しかも会員サイトなら他人に迷惑かかるから止めたほうが良いと思う

412 = :

ボコボコになるだろうな。情報も少ないし、困った時も解決しづらい。

415 = :

>>414
結合させるモデルの両方共プライマリーキーじゃないんです。
なので、動的切替は無理かと。

419 = :

>>418
分かりました。難しいですが勉強します。ありがとうございました。

422 = :

多重配列になるのが嫌なら、それこそafterFindで調節する手もあるな。
どちらにしろフレームワーク使うんだから、後々修正しやすい方がいい

427 = :

>>425
規模が大きくなるのならログイン必須であることを明示するためにもprefixあった方がいいかもだけど
一人で小規模でやるなら分けるほどでもない

428 = :

>>427
どの程度が「規模が大きい」から図りかねるのですが、
モデルが50ぐらいあるなら大きいって認識でいいですかね？
前述した通り、「一般的なベターなやり方」を教えて欲しいのですが・・・

429 = :

>>428
モデルというよりコントローラーの数によるだろうけど、それだけでかけりゃ分けた方がいいよ

一般的にベターとか言われも、例えば規模が本当に小さければcakephpなんて使わずに
phpの1ファイルで実装した方がいい場合もあるわけだし
規模感無視して一般的な話をしようとしても無理だよ

430 = :

今、cakeを勉強中なのですが、他のフレームワークを今まで使ったことがないのでわからないので検討違いかもしれないですが、
cakeのモデルって使い勝手悪いのですが、これがフレームワークでは普通なのでしょうか？
アソシエーション定義してもrecursiveの深さを検索するとかこんなもの使い道あるのでしょうか？
テーブルにただマッピングされてるだけのsql発行クラス以上の使い方があるのでしょうか？
っていうか、このモデルというのは使い勝手がいいのですか？

431 = :

>>430がRDBMSさえも理解してない素人なのか自前でORマッパーを作りかねない玄人なのか判断つきかねる

432 = :

>>429
フレームワーク使うのに、小規模ってことは無いと思うんです。
例えば「お問い合わせフォーム作りたいから使おう」とか「会社紹介ページ作りたいから使おう」
ってレベルの人がフレームワークに立ち寄らないと思うんです。

それより規模がでかくて数々のプラグインや便利ツール（ヘルパー・コンポーネント等）
があるからフレームワークを使おうと思うわけで。

そしてもうひとつの利点である「開発方法を定める」ってのもあると思うんです。
命名規則やMVCの考え方など、1人でやってたらその都度変わりそうな要件も
フレームワークを使うことで統一する事が出来るし、それは後の改修のしやすさに繋がる。

だからこそ「一般的でベターな方法を追求する」事ってメリットがあると思うんですよ。
そこにメリットが無かったり、「人それぞれじゃね？」ってなると、
それこそオレオレフレームワークと変わらない気がします。

>>430がフレームワークを使おうと思ったキッカケも、
「自分一人の考えで済ませたくないから」じゃないですかね。
そして過去の自分の経験・考えがあるからこそ、
「Cakeのモデル定義は使い勝手が悪い」という判断ができるわけで。

だからやっぱり「自分の好きな様にやれよ」って言われても、しっくり来ないんです。

434 = :

>>431
sqlもおぼつかないど素人です。

>>432
>だからやっぱり「自分の好きな様にやれよ」って言われても、しっくり来ないんです。

そうですね、なにか他人と共有できるものを獲得できるようにフレームワークで一番最初に引っかかったものいじってみたしだいです。


よくわからないので、とりあえず青い鳥を探してがんばってみることにします。
ありがとうございました。

435 = :

>>432
いわんとすることはわかるけど、cakeでもコントローラー10個以下の小規模なものと
コントローラー100個以上の大規模なものでは、cakeという規約の上でも開発ポリシーは変わるよ
もちろん参加メンバーの多寡でも変わる

たとえばcakeはキャッシュ先をファイルとapcとmemcacheとredisに対応してるけど、
決してデフォルト設定のファイルキャッシュが多くの場合にベターな手段であるということではない
最終的に自分の案件でなにを使うか決めるのはやはりそれぞれの開発者だよ

436 = :

>>435
フレームワークを使わない場合、
ファイル管理は主にフォルダ分けで対応していたと思うんです。
そのフォルダ分けがコントローラー分けに変わっただけで。

でも、コントローラーを分ける理由てファイルが肥大化して読みにくくなるからで、
1コントローラー1アクションを実行するCakeの場合、
パフォーマンスに大きく影響はでないと思います。

ただ、その「ファイルが読みにくくなる」というのは開発効率の面で大きな問題ですし、
バグのリスクが高まるなら、素直にファイルを分けたり、
プラグイン化するのも大事だと思います。

その、「どれぐらいの量に達したらこうするべき」って指標があれば良いんですけどね。
それはあくまで要件次第って事が難しくさせるんです。

基本的に誰しも最初は小規模の物を作るだろうし、
継続して運営していくようなものなら後から機能を追加して大きくなっていくと思うし。

とりあえず、会員専用ページのURLやコントローラー構成に「こうするべき」
という指標はないということで納得する事にします。色々とありがとうございました。

437 = :

「sqlもおぼつかないど素人」を自称する430が、
Cakeのモデルを「使い勝手が悪い」と評価した理由や経緯に
興味があるんだけれど。差し支えなければ教えて欲しい。

443 = :

>>441
ベリファイ処理の時の完了フラグ建てとくとか？
少なくともCakePHPに求める機能ではないね


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

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

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