[PR]馳凡g\
g選

¶ グローバルメニュー
¶ 短信タイトル

HTML自動出力時に渡すページデータ

¶ 短信空間内の前後移動ナビゲーション

Clip
¶ 短信本文
2006-03-11 23:38
いやー、真央ちゃん残念だったねー、まるでわが子を見守るようなハラハラしっぱなしの気持ちでストリーミング観戦してましたよっていう話はいいとして、久しぶりにHTML自動出力のお話で、この手の話はMVCってことになるのが常なんだけども、どうも「手法」のほうが先行している感じなので、もっと大切なデータ君の側からMVCプロセスを見てみました。
2006-03-12 03:06
「MVC」ってのを簡単におさらいすると、MはModel、VはView、CはControllということになってんですが、いまいち分かりにくいですね。だいたい「MVC」という並びからしてプロセスと違っているような気もするんだが……。
 M Model     DB                  RDBMS  データソース部
 C Controll  Webアプリケーション Apache データ制御部
 V View      WWW                 CGI    ページ表示部
2006-03-12 03:10
一番右側のがおら風みんな解釈。DBに限らずあちこちに散在しているデータ群……場合によっては外部のネットワークかもしれない……を「データソース部」と呼んでみる。これらのデータ群からページに必要なものを集めて各種編集加工を施した後、Webページを表示する部署に回す……こういうプロセスだと思います。だから肝心のデータ君からすると、「MCV」と言うのが正解なのかもしれないな。で、CとVってのは、データ側からすると「なんらかのフィルタである」というように見えるのかもしれない。
    M          C                         V         末端出力
 ┌──┐  ┏┳━━┓  ┌────┐  ┏┳━━┓  ┌────┐
 │Data├─→┃Perl┃  │Hash    │  ┃┃TT2 ┃  │HTML    │
 └──┘  ┃┃    ┃  │        │  ┃┃    ┃→│        │
 ┌──┐  ┃┃    ┃  │        │  ┃┃    ┃  │        │
 │Data├─→┃    ┃→│        ├─→┃    ┃  └────┘
 └──┘  ┃┃    ┃  │        │  ┃┃    ┃  ┌────┐
 ┌──┐  ┃┃    ┃  │        │  ┃┃    ┃→│CSS     │
 │Data├─→┃    ┃  │        │  ┃┃    ┃  │        │
 └──┘  ┗┻━━┛  └────┘  ┗┻━━┛  └────┘
2006-03-12 03:14
ページに必要なデータをどうやって View部門に渡すかということですが、いろいろ考えてみた結果、無名ハッシュにまるごと保管し、そのリファレンス一個のみを渡すってのが簡単でいいんじゃないかと思うようになりました。当然Perlの話なので、Controll部門は、散在するデータ群から必要なものを集め、編集・加工し、一個の無名ハッシュデータ構造体にカプセル化するのが役割。この場合のView部門は「Template Toolkit」(TT)を想定していて、受け取った無名ハッシュの中身を解析して、ページ内に割り振るのが仕事。解析ってもハッシュ構造だからキーが必ずあるわけだし、そんなにしんどくはないはず。もちろんCとVではデータ構造の様式は事前に厳密に確定しておく必要はあるだろうな。View部に勝手に文言弄られないぐらいに、徹底してカプセル化しておく(笑)。
2006-03-12 03:51
上記の処理は、「末端ページには人間は一切手を出さない」という原則の上に成り立っております。例外となるのがCSSファイル。CSSは完全にViewマターなのでControll部がコントロールするわけにはいかないわけですが、必ず末端のCSSファイルを直接弄くってしまっているよね。おら的には、このCSSも支配下においたほうがいいと思っております。具体的には、View部隊が弄くるのは「CSSソースファイル」であり、修正かけるたんびにコンパイル(コメント除外したりのパック化)して、表示を確かめるべきなのかもね。試験的には、CSS部分もTTでテンプレート化してみてたりすんだけどね、いやー面倒くさい(笑)。
2006-03-12 03:55
CSSをテンプレート化するとことのメリットは、非力なCSSにPerlの強力な繰り返し処理や変数代入処理を組み込むことで、ケアレスミスを少なくできるってあたりだろうか。ソースファイルをPerl風みんなコメントが書けるの大きい。Perlに慣れると、コメントの両サイドをタグで囲むスタイルに疲れるんだよね(笑)。徹底してコメント化しておけば、あとで全体を改修するときにも相当楽できるだろうし、無様なコメントを外部に曝すこともなくなるかな。(´Д`;)
2006-03-12 06:49
View部には文言を一切弄らせないわけですが、これはControll部でも原則同じですか。どっかからもってきたデータを加工することはあっても、Controll部内ではデータをゼロから新規に起こさない……これはつまりはControll部を担当するPerlスクリプト内では、コメント以外に日本語を使わないってことでもありますね。データ本体の新規登録・修正はModel部であるデータソース部門が行う……当たり前すぎて涙が出てきそうなわけですが、辛抱できずに「えいやっ!」とスクリプト内でついついやっちゃうわけですよ。その結果が見通しの悪いスクリプトになってしまう。どどのつまりは、Controll部からHTMLのタグやprint文を排除するだけではダメで、裸のデータそのものも排除する必要があるだろうなというお噺。
2006-03-12 06:59
しかしながら原則は原則でしかないわけで、例えば人名につける「様」は、どの部門が担当すればいいのかといった卑近な話が出てきます。データ本体がもつのはおかしいし、かといって司令塔であるCが付加するのもおかしいので、「様」を必要とするシーンのViewマターとなりそうです。「様」は果たしてデータなのかという話もあるでしょう。しかし、「様」ではなく「殿」を付加したがる旧式のView部門があったりすると、トーナリティは一気に損なわれます。「人名の接尾語は『様』に統一」という協定を結ぶか、徹底した性悪説の立場をとり、「$human_suffix = q{様}」とか制御しようとするのか(笑)。データそのものはModelマターだから、用語や送りの統一とかはModel部門にトーナリティを司る編集担当マネージャを配備しておけばいいんだろうけどね。でもあれか、いまだにDB入力・メンテ部門なんてのは女工哀史的なノリで低く見られてたりすんのかなぁ……。上のモデルで言えば、MCVは対等の立場でテーブルを囲み、データから見ると、CのWebエンジニアやVのWebデザイナーよりかは、Mの編集者のほうがちょっとだけ立場高いんだろうけどね。

Clip


ときどきH264コーデックを使った動画を見かけますが、確かに再エンコードできないので困ってましたが、このページに答えがあります。結論としてSUPERというツールで可能なんだけど、すげー時間がかかるような気がする。この世界も日進月歩・秒進分歩なのであろうな
各CPU別のH264コーデックの日本語化パッチが置いてあるページ。本体の入手先もまとめてある。日本語化パッチと同じ版の本体をgetしてINFファイルから右クリックでインストール後、任意の場所でパッチを実行。VirtualDubModで読み込む場合は、WMVと動揺にDirectShow経由で読み込めばOKのはず