「そこまでこだわるべきなのか」　←言いたいこと
「でも、そこまで言うぐらいだから、こだわらないと困るのか」　←疑問

>>499
>>496に「とらわれすぎると」って書いてあるだろ、
場合によってはMVCの枠組みに落とし込む事がデメリットになるって話。

例えば、数行で済む使い回し不要のコードの為にモデルを量産すると
管理が面倒だし、他との依存関係が不透明になるからロジック変更の時に面倒だよね。
そういう場合はCなりに埋め込んでしまう方がいいんじゃね？

って話。

そんなのコメントしとけば依存関係は不透明にならんだろ。ただの怠慢でMVCのせいにすんな。

コメントで他のコードのどこから参照されてるか、全て把握かつ保証出来るんだ？
503さん、まじパねぇっす！

503さんはエスパーなんです！

>>494
サーバ専用処理って。。。
逆にクライアント処理をPHPで書いてもらいたいな

>>506
入力も出力もなく
サーバ内で完結する処理という意味だろうけどね。

>>506

大丈夫か？
頭打ったろ！

ザックリした説明に一々噛み付く馬鹿！
夏はイロイロ湧いてくるなぁ

自分の頭に無い解釈＝不正解

だというプログラマーが多すぎです

まあ、あながち間違ってはいないがな。

いや、間違ってるだろｗ
その理論だと世の中全てのPHPコードがMVC実装されてる事になる。

いや、それは「PHPでMVCを書いた」って事で
Smartyみたいに元から実装されている分けじゃないんでは？

キャッシュって使うもんなの？
Smartyだと使わされるもんだと思ってたよ。

>>518
コンパイル済みテンプレートとキャッシュを混同してるだろｗ


俺は使ってない。
本当にキャッシュが必要なページはrenderしたものを自前で静的htmlファイル生成化してるわ。
1時間に一回再生成するようなページで使えば楽んだろうけど、レアケースだよね。

>>519
批判じゃなくて興味本位だが、
なぜSmartyのキャッシュじゃなくて、自前なの？
Smartyで同じ事出来るよね？

キャッシュ使うとテンプレートの更新が反映されないんだが
更新したらキャッシュ切らないとだめなの？

>>520
Smartyのキャッシュって、
PHP呼び出し → Smartyインスタンス生成 → キャッシュ確認 → 出力
という処理が入るから、生成されたHTMLファイルに直接アクセスする場合と比べると負荷はかかるんだよね。

519にも書いたように定期的に自動で再生成するような場合は楽だけどさ。
自分のやってるシステムでは、管理者が任意のタイミングで再生成するのがほとんどだから、自前で実装している。

DBからのデータを差し込みつつ、出力をキャッシュするってページはあまり無いからなぁ…。

>>521
テンプレートを更新したらキャッシュを削除するのが、
一番手っ取り早いし、確実だと思うよ。
>>522
なるほど。俺は、テンプレート（ヘッダーフッターなど）を
DBで管理しているんだが、
テンプレート内にもSmartyタグを使ってるから、
自前のキャッシュファイル生成だとそれらが反映されずに困るんだよな

>>523
ん？DBから動的に書き出す(+Smartyタグを処理する)場合ってキャッシュは使えないよね？
コンパイル済みテンプレートの事？

俺の中では
キャッシュ … DBデータ等の差し込み済み出力結果を静的に保存する。
コンパイル済 … SmartyテンプレートをPHPコードとしてキャッシュする。
って定義なんだ。
これが正しいかはわからない。誰が偉い人まとめて！

キャッシュするなキャッシュ自体に期限を設けるのが一般的かな、
毎回DBからデータを持ってくるのであれば、
それは事実上キャッシュは不可能。

コンパイル済テンプレートのキャッシュは常に有効にしておいて良いと思うよ。

テンプレート自体をDBに格納してるって話じゃないの？

え？

へ？

>>525 の意味がいまいちわからんのだが…
キャッシュの有効期限とかどうしてるの？
設定してあれば on / offしなくても自動でキャッシュ更新されるし、
設定していないのであれば、キャッシュは生成されないだろうし。

上にもある通り、キャッシュとコンパイル済テンプレートの認識が混ざってないかい？

え？

テンプレートってDBとかに格納しておけるの？
できるならすごい便利なんだが

>>532
できなくはないでしょ

>>532
Smartyヘルプのリソースプラグイン読んでごらん。
まんまDBからテンプレート取得するコード書いてあるから。

できなくないのは分かるけど
いまいちどういう時に使いたいのかわからん。
ファイル名でマッピングしておくのと何が違うんだろ？

>>535
updateコマンドで一括変更したり、日にちでサイトをガラッと変えたりするんじゃね

>>535
CMSとか作る場合には良いんじゃないかね。
管理画面からの検索や更新、バックアップが取りやすい。
あとはWEBサーバが冗長化されていて、リソースを一箇所に纏めたい場合とかかね。


制作の手間暇考えたら、メリットは薄いと思うけど。

>>535
ファイルをDBで管理すると、WEB上から更新できるならな。
しかし、複数アカウントを発行して利用するシステム（MTなど
の場合は、システム毎にテンプレートを編集できるので
ファイルで管理するより便利。メリットは絶大だと思う。

いや、その用途なら普通にファイル編集orアップローダのが楽だろ…

>>539
DB分かってる人ならDB使うのがラクだと思えるよ。
ファイルはすぐ腐る。

少し腐ったぐらいが美味しい...

ファイルは数が増えるとどんどん大変になるんだよな

システム作る側は楽かもね。

デザイナの大半はローカル環境でコーディング、一括でアップロードを望んでいる。
またテンプレート自体がバージョン管理下に置かれている事も多々ある。
運営する上でDBに流し込み作業が発生するのは楽ではない。

ディレクトリ分けもせずに700個のHTMLと格闘してる奴を見てるとホント馬鹿だと思えてくる

そんな奴いねーよｗ

700個のHTMLって時点でテンプレートを活かしてない感じが…

テンプレどころかCSSすら使ってないんですわ、マジで。

でも場末のウェブ制作屋ってほんとひどいからね。
ちょっとかじった中学生か、ってレベルのおっさんが
見てて頭痛くなってくるような非効率的な作業環境で、
素人騙して金貰ってるようなとこいっぱいあるぞ。

>>543
流し込み作業をプログラムですれば良いだけだろ
一括アップロードと変わらん

>>549
それやってしまうとファイル管理のメリットも、DB使うメリットも薄れてしまう気がするんだが。