このブログは、旧・はてなダイアリー「檜山正幸のキマイラ飼育記 メモ編」（http://d.hatena.ne.jp/m-hiyama-memo/）のデータを移行・保存したものであり、今後（2019年1月以降）更新の予定はありません。

今後の更新は、新しいブログ http://m-hiyama-memo.hatenablog.com/ で行います。

マイクロアップの概念・用語、流儀・作法・掟

メモ Caty MicroApp

基本的に、マイクロアップを分散アプリケーションと考える。Web上に分散されたデータとコードからアプリケーションが構成されている。何をどう分散させるかが問題だ。実は普通のWebアプリケーションと変わらないし、変わるべきではない。

  1. データリソース、データオブジェクト、リソースストレージ、データソース； まー、だいたい同じこと
  2. リソース抽出器：URIに対応するデータリソースをリソースストレージ（データソース）から取り出す機能
  3. データリソース内容の表現形式はJSON
  4. 構造ビュー（structure view）＝クリーンHTML
  5. クリーンHTML：装飾、デザインを含まない。純粋なセマンティック・マークアップされたHTML。
  6. 構造ビュー生成器：JSONデータからクリーンHTMLを生成する、ほぼテンプレートエンジンのこと
  7. サービスエンドポイント：今（マイクロアップ）のケースでは、リソース抽出器、構造ビュー生成器にアクセスするURLのこと。
  8. 最終ビュー（final view）＝スタイルドビュー（styled view）：ページ閲覧者が目にするビュー
  9. JSONベースRESTスタイルAPI：データ形式としてJSONを利用する
  10. HTMLベースRESTスタイルAPI：データ形式としてクリーンHTMLを利用する
  11. Microformats方式マークアップ：データリソースのJSON形式表現からクリーンHTMLを生成するときの流儀と作法。可逆性がキモ。
  12. 生成リクエスト：マイクロアップのロードと初期化のときに使うリクエスト。ビュー生成用に、JSONまたはHTMLを要求する。
  13. 対話リクエスト：マイクロアップが動作中に使うリクエスト。ほぼ非同期メソッドコール。
  14. サブミットリクエスト：ページまたはマイクロアップが、終了して次のページに遷移するときに使うリクエスト
  15. レスポンダ：マイクロアップからの対話リクエストに応えるサーバーサイドプログラム・モジュール。API実装プロバイダ。
  16. マイクロアップの表示エリア：div, iframe, 別ウィンドウなど。
  17. マイクロアップの寿命： 通常は、ページと同じか、ベージ寿命の一部分。長寿命マイクロアップはページをまたいで生きる。
  18. ポーリング：天気予報、株価、チャットなどに使う。
  19. ポーリングライブラリ：これはフィーチャとして必要だろう。
  20. 通信ライブラリ：WCCのTranceiver.jsに相当。maTranceiver.jsとかを作るか。maTranceiver-ajax-0.1.js などが具体例。
  21. フィーチャ確認コード：ビュー生成（ローダー）のJavaScriptコード内でフィーチャの存在は確認した方がいいかもしれない。
  22. 分散配備：マイクロアップの素材を適切な場所に配備すること。
  23. リロケーション：分散配備の配備レイアウトを変えること。
  24. リロケーション対策：リロケーションの影響を最小化する方策
  25. 通信方式：現状でサポートできるのは、ページ遷移、Ajax、ODJSの3種
  26. マイクロセッション：マイクロアップとサーバーサイドプログラム（レスポンダ）の間のセッション概念。まだ未定。

流儀・作法・掟：

  1. データリソース、コードリソースにはできるだけ細かくURLを割り当てる。
  2. 拡張子は、.json, .html, .cgi（コードリソース）を使う。他に意味的な拡張子を使ってもよい。
  3. データ表現は必ずJSONを使い、スキーマを書く。
  4. データであるJSONに対して、表示の骨格を与えるクリーンHTMLを設計する。
  5. クリーンHTMLはMicroformats方式でマークアップして、可逆変換（JSONへ戻し）ができるようにする。
  6. JSON -> HTML はテンプレートで定義する
  7. HTML -> JSON はCSSデータ抽出言語（別に記述）で定義する。
  8. CSSデザインに必要な要素、ID、クラスを追加してもよい。CSSセレクタ仕様を明確化。
  9. データオブジェクトに対する抽象メソッドを定義する。
  10. 抽象メソッドはメイヤーのクエリー・コマンド方式にする。
  11. 生成（コンストラクタ）と対話リクエスト（メソッド呼び出し）のプロトコルを設計する
  12. プロトコルと状態遷移の関係を明らかにする。
  13. 状態には、フロントパートの状態とバックパートの状態があるが、全状態（トータル状態）に注目する。
  14. 全状態のフロント・バック分解は恣意的かもしれない。
  15. そもそもフロント・バック境界が恣意的。
  16. 分散配備レイアウト、通信方式は具体個別的だから、できるだけ切り離し、影響を受けないようにする。
  17. マイクロアップのローディング方式はさらに具体個別的・物理的だから注意。

集中すべきことは：

  1. データの単位的実体（unit entity）であるオブジェクトをJSONスキーマで定義する
  2. データオブジェクトのコレクション編成方式を考える。
  3. コレクション編成は、リスト、バッグ、セット、マトリックス、ツリー、グラフなどと、それらの組み合わせ。
  4. コレクションもJSONスキーマで定義する。（できるはず！）
  5. データオブジェクト（通常はJSONオブジェクト）に対するメソッドを考える。
  6. コレクションに対するメソッドを考える（まずはCRUD）。
  7. 以上の設計要素をまとめて内部的抽象インターフェースを確定する。
  8. データオブジェクトとコレクションに対してMirocformtsマークアップ（テンプレート）を定義する。
  9. 「JSON⇔HTML」可逆性を保証するために、CSSデータ抽出仕様を定義する。
  10. CSSデータ抽出をもとにCSSセレクター仕様も書く。これがCSSデザイナとの合意事項になる。
  11. 内部抽象インターフェースをURLにマップする。
  12. URL群は外部インターフェース（公開API）となる。
  13. 内部抽象インターフェースと外部インターフェースの差はできるだけ小さくする。
  14. URLの拡張子は、.json, .html, .cgiとするが、.cgiをできるだけ使わないように心掛ける。
  15. ODJSを使う場合は拡張子を、.json.js, .html.js とする。単なるコードライブラリは、副拡張子を使わない。

URLと拡張子の掟：

  1. JSON（で表現した）データを .json とする。
  2. クリーンHTMLフラグメント（で表現した）データを .html とする。
  3. 同じベース名の .json と .html は等価でなくてはならない。
  4. コード実行を提供するプロセッサ・リソースは .cgi とする。
  5. プロセッサ実行結果がキャッシュ可能なら、.json, .html として提供する。
  6. コレクショリソースに対するPUT, POST, GETはディレクトリURLを使う。
  7. 動詞は _verbパラメータ。
  8. JSONP, HTMLPのコールバック名は _cbパラメータ。
  9. クエリ文字列の長さは _qsl パラメータ。壊れていると、BadRequestになるだろう。
  10. チェックサム（ダイジェスト）を入れたい場合は、_csパラメータ。
  11. APIキーを入れたい場合は、_apikパラメータ。これはPOSTでも使う。
  12. JSONPを提供するURLは、foo.json.js?_cb=mycb
  13. HTMLPを提供するURLは、foo.html.js?_cb=mycb
  14. foo.html.jsの_cbパラメータが省略された場合は、HTML body内での展開をするようにする。
  15. JSONデータ、またはHTMLデータを受け取ってビューの初期化をするJavaScriptメソッドの命名は、initViewとする。
  16. foo.json.js, foo.html.js, foo.json.js?_cb=hoge.initView, foo.html.js?_cb=hoge.initView の結果は等価とする。
  17. ただし、foo.html.js がinitViewを呼び出すわけではない。foo.json.js はデフォルトでグローバル関数 initViewを呼び出す。
  18. 同一ページ内で複数のマイクロアップを共存させるために、名前空間の規則を守らなくてはならない。

キモと問題点：

  • 一番大事なのは、データ構造（基本データオブジェクトとコレクション階層）に対するスキーマを定義して、内部的抽象インターフェースを策定すること。スキーマ言語はあるが、インターフェース定義言語（IDL)がないのが問題。当面はJavaで代用か？
  • 内部抽象インターフェース（スキーマ定義を含む）があれば、URL設計の指針が得られる。
  • JSONスキーマがあれば、クリーンHTML（＝構造ビュー）設計の指針が得られる。CSSデータ抽出定義で可逆性を保証できる。
  • フロント・バック間通信のプロトコルとページ遷移に対する良い記述言語（図解法）がない。
  • セッション、マイクロセッション、長寿命マイクロアップの概念が曖昧。
  • ユーザーアカウントとマイクロアップの関係が曖昧

CSSデータ抽出：

  1. cssdx.element(selector) -- 要素そのもの（1個）
  2. cssdx.content(selector) -- 要素コンテントのデータ
  3. cssdc.attrVal(selector, attrName) -- 属性値のデータ
  4. cssdx.childElements(selector) -- 要素内容の子要素だけをリストにしたもの
  5. cssdx.as(expr, typeName) -- exprの値をtypeName型とみなしたもの

単純JSONパスと組み合わせて、対応を完全に記述する。