動的生成のメリット、静的生成と「ゴミ」。

動的生成のメリット

再構築! 再構築! 再構築! ばかり書いてるけど、僕はケースバイケース派ね。ていうか当然だけど。

明らかに動的生成が有利というか動的生成じゃないと困難なケースをいくつか挙げると (全部あたりまえの話ばかりだけど)、

1. クライアント毎に返す結果を変えたい場合。携帯電話向けウェブアプリの場合等。絵文字とか機種毎の差を反映させるためには静的生成の場合はUA毎のすべてのページを生成しなければ不可能。
2. ユーザー毎にログインを必要とする場合。
3. リクエスト毎にリアルタイムで処理を行いたい場合。例えばリアルタイムにアクセス解析を行う場合等 (最近は見ないけどカウンタとかも)。

こういう場合における負荷分散とかクライアント/サーバーそれぞれにおけるキャッシュの実装とか、そのあたりが腕の見せ所になってくるわけですが、1.の場合であれば各キャリアで共通の部分をサーバーキャッシュ、リアルタイム更新の不要なところではクライアントキャッシュを使わせるとか。2.の場合は実態はスタティックなページを返しても良いので「前処理」の部分で認証処理を行うようにして、認証をパスしたら静的データを返すとか。3の場合も1と同様、動的処理が不要なところは同じくサーバーキャッシュとか。
もちろん動的生成が効率よく行われるような組み方をするのが大前提だけど。

というのを考えたのはVOXってどうやってるんだろう? と思ったことが一つと、MTの静的生成のもう一つのデメリットである「ゴミ」が出来る問題について昨日ちょっと話題に登ったから (というか僕が話題にのせたのだけど)。

静的生成と「ゴミ」

静的生成と比較した動的生成の最大のメリットは「ゴミ」が出来ないこと、というかファイル管理の必要がないことだと思う(速度や負荷の話は不毛なので敢えてここではしない)。だからサイト制作段階においては動的生成、納品・公開時には静的生成とか、そんな方法も(ウェブ屋的な使い方としては) あり得る。

ゴミの件はそのあたりを掃除するプラグインを書くのは実は簡単で、これもラフラフなバージョンは出来ていて、CMSのViewのところでAjaxとか使おうかなぁと思ってウチのV担当に指示して作成中なわけで、CMSの拡張においてもちゃんとVとCが分担出来るMTって素敵とか思う今日この頃。

MTの静的生成と「ゴミ」についての関連エントリー

• CMSと静的ファイル管理に関する考察。
• CMSと静的ファイル管理に関する考察の続き。
• CMSと静的ファイル管理に関する考察の(更に)続き。
• DeleteFilesAtRebuildの半端さ加減。
• ステータスが「下書き」のエントリー(permalink)が残っていたら削除する。

さて、いよいよMT4

まぁ雑文ですが、本日V4リリースだよね。さっきの段階ではまだ見つけられなかったので取り敢えずRC4落として新幹線の中でいじってみることにします。

おそらく遅くまでバタバタされたであろう中の方にはお疲れさまと言いたいです(が、まだ本番はこれからです! 引き続きよろしくお願いしますね)。