トップ «前の日記(2006-11-09 [J]) 最新 次の日記(2006-11-15 [J])» 編集

Eroge RSS Checker 運営記録

Categories | メモ | 運営 | 感想 | 記号変更 | 雑記 | 雑文 | 思案

合計: 今日: 昨日:
2006年
11月
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30

rss1.0

ここは、「Eroge RSS Checker」に関する運営の記録を書きとめておく場所です。第三者に説明する文体で書いていますが、大半は備忘録です。

  1. スクリプトを汎用化して公開する。---最終目標
  2. CSSを論理的に使う。---努力目標
  3. デザインを改善する。---努力目標
  4. 攻略の完全・不完全を出来る限り判別する。---努力目標
  5. 管理要員用のページの充実。---努力目標
  6. JANコードの入手先を探す。---躊躇中
  7. ブランドの複数登録。---大規模改修のとき
  8. 登録を簡潔にしつつ、marker登録を半自動化する。---暇なとき

2006-11-10 [J]

_ [メモ] 「CakePHP」雑感

ちょっといじってみた。MVCに分かれているけれど、V(ビュー)にほぼ全部書くなんて馬鹿げたことも可能。M(モデル)はデータベースのテーブル単位でファイルを作り、そこに他のテーブルとの関係や固有の処理なんかを書くんだけど・・・・・なんとなく、MVCの中で影が一番薄いかも。C(コントロール)は処理で一番重要な部分、個別の処理はほとんどここに書く。MVCは個別のファイルだけれど、ファイル名に規則があって自由には出来ない、そしてCのクラスの中の関数名がそのままアドレスにもなる。ヘッダーフッター部分はlayoutsとして別ファイルに入れる。CSSやJavascriptとかも別。多用する部分はelements。

使って何が便利かと言えば、コードの量を減らせることと、整形化されること、命名規則を守ればDB処理が半自動化する(joinなど不要)ことなどです。反対に、結構多くの規則を覚えないと使いこなせないので、導入コストは高くつきます。また、既存のシステムの移植労力はどれだけMVCに分けられているかで違ってきます・・・。

アドレスの右端に標準で「/」が付かないのが、なんだか気分が悪いけど、そんなに悪くもないかも。CakePHPが大いに普及すれば、機能追加も容易になるし、ERCの可能性も高まりそう・・・。

ただ、フレームワーク云々より、重複部分の切り分けをきちんと出来るか、出来るとしたらフレームワークを使った方が効率的かは分からない。それに、今よりも確実に重くなる。特にキャッシュ機能はお手製なので、CakePHPのDB周りとの共存は無理そう。

現状、PHPのフレームワークの中では一番良さそうだけど・・・・さてどうするか。

お名前:
E-mail:
コメント: