Hatena::Grouperlang

檜山正幸のErlang未確認情報 RSSフィード

2009-04-03 (金)

cathandメモ

| 11:14

どこに書いたらいいか迷ったがココにする。[連絡的]というタグが付いたエントリーは、檜山本人と身内しか意味がわからない。それでも公開で書くのは、内輪の連絡からでさえなにがしかの情報や示唆を得る人がいないとも限らない、と考えるから。

基本は T. Parrの論文

コンテキスト(Parrのいう属性)概念がキモ。コンテキストをコアコンテキストと拡張コンテキストに分ける。コアコンテキストはプログラマが準備し、拡張コンテキストはデザイナが必要なら準備する。拡張コンテキストを構成する素材は

  1. ファイルシステムディレクトリツリー)そのもの
  2. 定数ファイル(拡張子 .const

定数ファイルは便宜上のもの、あれば便利そうだから入れただけ。

コアコンテキスと定数ファイルは、リテラル値を提供する。リテラルのなかにはもはや変数(プレイスホルダ)がない、値そのもの。テンプレートがさらにテンプレートに展開される再帰処理は、すべてデザイナの責任、プログラマは無関係。

ファイルシステム内のファイルがテンプレートリテラルかを判断するのは、ファイル先頭に埋め込まれた宣言を使う。その他のコンベンション拡張子とか)、設定は使わない。「ファイルパスと宣言のあるなし」の関係は効率のためにキャッシュされる。


考えるべき事は:

  1. パスマッピング -- URLローカルファイルの対応
  2. テンプレートの構文と能力 -- 純関数型、モナド
  3. コンテキストサーチ -- URLやリクエスト情報からコンテキストを探す、または生成
  4. コンテキスト管理 -- コンテキストは寿命を持つので管理する必要がある。
  5. 変数に対して値がないときの処理 -- ここは、理論と現実のギャップを埋めるところ。

理論上は、リテラル値(定数)とテンプレート(式)をさほど区別する必要はないが、現実にはウルトラ厳密分離の要求があるで、値とテンプレートはまったく別扱い。プログラマからは値しか見えないし、値(構造的値)だけでテンプレートインターフェースする。

テンプレート展開エンジンは、純粋なモナド実装。つまり、Kleisli圏の結合を計算するだけ。リソース管理などを入れるとロクデモナイことになるので、直接にファイルを触ったりしては絶対にダメ。このへんはDIっぽく作る。ファイルリソースも含めてコンテキスト(チェーンに編成される)を準備して、それをテンプレート展開エンジンに渡すのはエンジンを使う側の責任。


「これはテンプレートだよ」と宣言するのは、テンプラのコメントを使う。

  1. 先頭から3行目までなら宣言開始行を書ける。(4行目以降は探さない)
  2. 宣言そのものは消すが、その他は改行も含めて残す(出力に送る) -- 仕様変更
  3. 知らない属性(Name = "Value" 構文)をエラーとしない。
  4. 複数行に渡って書いてもよい。

例:

<!--
{*! template="true" 
    context="../foo.ctx" 
    constants="../../const.const" *}
-->

心変わりしたところ、要求、目標

| 18:13

昨日から今日で心変わりしているのだが、それは、プログラマプログラミングだけする人)とデザイナ(その他のことをする人)を対称的にしようと思ったこと。実際には、プログラマとデザイナの中間の人とか、両方できる人とか、ディレクターだか何だかどっちでもない人とかがいるが、単純化して考える。

  1. サイト全体の構成に関しては、プログラマが主導でもデザイナが主導でもどっちでもいい。
  2. フォーム送信データのデータ形式、ページに対するコンテキストのデータ形式をデザイナが決めてもいい。
  3. いずれにしても合意は絶対に必要だが、合意事項=仕様はデータとして残る。
  4. 仕様が決まったところから並行作業ができる。
  5. 合意事項=仕様の変更時にはコミュニケーションが必要(これはどうにもならない!)

どっちでもよくない作業は:

  1. データベース設計とビジネスロジックプログラマの責任
  2. プレゼンテーションユーザビリティはデザイナの責任

合意事項=仕様さえお互いに守っていれば、かつ信頼関係があれば、コミュニケーションコストは最小になる。

それと、非常に重要なことは、互いの進捗にかかわらず担当部分のテストができること。デザイナはプログラムがなくてもプレゼテーションの確認ができるし、データのやり取り(例:フォーム→DBテンプレート)のおおよその確認もできる。同様に、プログラマプレゼンテーションなしでもテストができる。

どっちかというと、デザイナ側のテスタビリティのほうが緊急の話。次が要求:

  1. ローカルファイルシステム+ブラウザだけでもプレゼンテーション(見た目)のおよその確認ができる。
  2. ローカルファイルシステム+ブラウザだけでもリンクをたどることができる。
  3. ローカルファイルシステム+ブラウザだけでもCSSの効果やJavaScriptAjaxではない)の確認ができる。
  4. ヘッダ、フッタなどのお決まり部品のメンテナンスが容易。
  5. サイトコンテンツ(単一ZIPファイル)をアップロードするだけで配備完了。
  6. プログラムまったくない状態でも、動的ページとフォームが動作する。
  7. データベースの代わりに、簡単なテキスト形式データ(たぶんJSON形式)をダミーに使える。