元スレ【PHP】フレームワークについて語るスレ10【総合】

php覧 / PC版 /

みんなの評価 : ○

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

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

401 = :

しばらくsymfony使ってて
久しぶりにci触ったら身軽でいいわ～

403 = :

>>402
ちゃんと使えば？CIのセッションについては、DBに保存することもできたと思うけど。

っていう自分はドキュメントよんで評価して改良してっていう手間がもうしんどくて、
guesswork classic をカスタマイズしたものを延々つかってるけど

404 = :

>>403

うん DB使うときはそれでいいんだけど
使わないときがね…

小規模だと CakeかCIがよさげなんだけどね
その改造する手間がね… orz

guessworkもためしてみるかな

405 = :

CakePHP ってそんなにDBと密接だろうか？

usesプロパティにnull代入すれば
それで終わりじゃね？

406 = :

>>405

それで一応できるけど
modelは必須なのが前提だし…

DB使うにしても密接すぎて融通きかない感じかな

はまれば楽なんだけどね

407 = :

普通に作ればモデルを作るのが当たり前なんだが・・・。
まあ経験をつめ。

409 = :

>>407

DBやファイル扱わない場合だってあるじゃん・・

410 = :

たとえば？

411 = :

それはどのFWを使うかというより、
FWを使うべきかどうかを検討する規模の開発だと思う。

生PHP+何かしら必要なライブラリで事足りそう。

412 = :

>>407
自分は、>>406じゃないけど、具体的にはどんな感じでモデル組んでます？

オンメモリな処理はともかく、DB上のデータに対しては、SQLの実行はパフォーマンスに
直結するから、内部の処理は隠すべきではないんじゃないかって思うところもあって、
結構悩ましい。

413 = :

内部の処理をモデルの中に隠せばいいのでは？

414 = :

だって、最適なSQLって画面とか機能ごとに違うことが多いじゃん。
画面とか機能からの独立性がほとんど無いものを個別に作り上げて、
それをモデルと呼べるのかといえば、かなり疑問。

っていうか、モデルとしてのメリットがほとんどない。

415 = :

MVCを勉強しなおしてね。

417 :

すべき

418 = :

だよな
ファイルシステムとの類推で考えると
同名のファイルとディレクトリは同階層に存在できないもんな

419 = :

どちらでも同じコンテンツにアクセスできることが望ましいと思うが、
どちらかに転送した方が良いと思われ

420 = :

質問スレで知ったんだがRhacoってどうなの？
和製フレームワークっぽいけど
このスレで出たことないよね？

421 = :

どうも和製はなぁ。

結局海外製に押し切られる気がする。
だからRubyもいまいち使う気になれない。

422 = :

Rhacoのオフィシャルサイトがなんか重いなァ
パフォーマンスでないのかな？

423 = :

結構作り込んである印象
なんでまったく話題に出なかったんだろ？

424 = :

>>416

それって他のFWもそうじゃない

その辺があまいのばっかだよなあ

425 = :

CIがあまいだけでは？

426 = :

>>418
おいおい。index.htmlを忘れているぞ。

hoge/moge/ だとmogeフォルダのindex.html（設定による）を参照すべきだろう？

427 = :

>>426
>>417-418は、まさにそう言ってるんだと思うが？

428 = :

いや、少し考えてみた。

URLが hoge/moge なら、一番最初に hoge/moge を探すべきだな。rewriteやaliasを含めて。
いきなり hoge/moge/ に書き換えるのは乱暴か

で、そうやって探して hoge/moge が見つからなかった時のみ、hoge/moge/(DirectoryIndex) と
するのが一応は順序かと思った。
>>426はそういう意味かな

429 = :

/hoge/mogeでも/hoge/moge/でもどっちでも
mogeがディレクトリ的存在だったら
/hoge/moge/index.html
が表示されるべきで、
その判断はサーバ側でおこなう。
最後の/の有無だけに、エンティティの判断基準を委ねない。
ってことだな

430 = :

なんかかぶったｗ

431 = :

>>430
結論は反対だけどねｗ

432 = :

ん？同じだろ？

436 = :

何を基準にした「正しい」動作なの?

437 = :

俺もｵﾓﾀ。いったい何を基準に正しい・正しくないを議論しているのか…
独自アプリのルーティングの話で index.html がどうとかﾜｹﾜｶﾗﾝ
静的ファイルを表示するための httpd を書いていて
mod_dir に酷似した挙動をさせたいということならわからなくもないが、
>>416が聞きたいのはそういうことなのか?

438 = :

パスが変わるのでしないべき
妥協点はスラ付きへリダイレクト

が正解

439 = :

>>438に賛同。
SEO/SBO という面で考えれば、/ ありと / 無しをアプリ側で同一と見なすべきではない。
ただし、ユーザビリティを考慮すれば、/ 無しを / ありに 301 で転送 (またはその逆) をすることをするとなお良い。
参考 →http://pmakino.jp/tdiary/20061105.html#p01

440 = :

なるほど
たしかにSEO的にリダイレクトする方がいいな
㌧㌧

441 = :

>>414
乗り遅れたけど、いい事言ってるなあ。
>>407とか>>415は流行に流されて本質を見失ってるな。

俺はテーブルと一対一になるモデル「じゃない」モデルクラスを作って対処してる。

442 = :

>>441
日本語が読みきれん。どっち？

テーブルと1:1に対応することを前提としないモデルクラスを作ってる
テーブルと1:1に対応する、内部の構造が隠蔽されていないから必ずしもモデルとは呼べない、モデルクラスを作ってる

前者だろうとは思うけど、一応。

443 = :

はぁ。テーブルと一対一にならなくても
モデルはモデルだろ。

444 = :

むしろ、テーブルと1:1になることを前提にするのは、内部構造に対する抽象化が制約されるという意味で、
モデリングとして不適切だと思ってる。

だから自分的には　>>443　は自明。
ただ、>>441 の言葉の意味が取りきれなかっただけ。

445 = :

クラスで使う例外って
クラスと同じファイルに書く？別にする？
例外クラスを1クラス1ファイル方式にすると
ファイルがとっちらかるよなぁ

446 = :

特定のフレームワーク上でのお作法の話ならずれてるかも知れんが、
自分の場合、自作の例外クラスって、せいぜい2個ぐらい (ユーザ操作系、システム異常系) しか作らない。

どんな例外であれ、rollbackしてエラーメッセージ出して終わりってのがほとんどだから、
クラス分けせずにエラーコードで区別してる。

447 = :

俺はタイプヒンティング使ってcatchするのに結構使うな

448 = :

>>446
せっかく例外という便利なものが使えるのに、
古臭く、使いづらく、バグが起こりやすい、
エラーコードを使う理由ってなに？

449 = :

>>448
例外の中でエラーコードを使うこと言うこと。
クラスの型で判別してないだけで、例外は使ってる。

450 = :

>>449　タイプミス訂正

例外の中でエラーコードを使っていると言う意味。
クラスの型で判別してないだけで、例外処理は使ってる。