コンテキストのバックアップの現在との差分(No.7)

to your Kindle

追加された行はこの色です。
削除された行はこの色です。

RIGHT:&tag(プラグイン);
RIGHT:[[:t/コンテキスト]] [[:t/型]] [[☆]]

PageElementを書けるところその2。例えばプラグイン呼び出し記法のパラメーターを書くところ。
ここにプラグイン呼び出しを書くとHTMLではなく再処理しやすいデータを生成する。（どんなデータかはElement次第）
Perlのスカラーコンテキスト／配列コンテキストのような仕組み。というか、ページやページ/要素を呼ぶときに、型指定できるだけのこと。
ページ/要素は指定された型のデータを返す。要素は内包する要素（下位要素）に同じ型を要求して…各要素が同じ型を返すために働く。返せない型でも一応返す。子要素の戻り値があればそのまま、無ければそれもそのまま返す。

その1はHTMLコンテキストと呼んでおく？もっと柔軟に。多彩に。
HTMLコンテキスト、ページ名セットコンテキスト、…のように。どんなデータをリクエストするかは土台になっているElement次第。そのリクエストにどう答えるかは呼ばれる（内側の）Element次第。
第一に考えるのはHTMLを返すコンテキスト。

----------
…をもっと柔軟にして…ページ/要素を呼び出す場面のすべてで使用可能に。呼び出し時に型指定。ページ/要素は指定通りの型''で''データを返すように。（型が変わっても同じ情報。型によっては欠けている部分があるかも知れないけど適宜対処）

データ型は統一しなければならない。参照可能ならいい。
Perlのリスト型ような。戻り値がリスト型・ハッシュ型2通りのI/Fがあってもいい。どちらも内容は近くなるように。
子要素は複数あるし、ネストしている。少なくとも要素同士の合成ルールが要る。
%%[[:/ページ要素間の連携方法,コンテキスト]]%%

%%PageElement構造上で同じ形式を扱えるelementがつながっていないと伝播しない。呼び出せないし戻り値も得られない。%%
%%標的までのパスがないときはDOM風アクセスで直接標的を決めてもらわないといけない。%%

----------------------------------------

子要素は複数あるもの。
それらの戻り値を合成する必要があるけど、合成ルールは親要素のコード次第。
適当にまとめて、型は変えないで。
特殊なことではないので専用ライブラリは要らない。
***[[:i/目次生成もデータコンテキストで]] [#q4efb20b]
-ToOutline
アウトラインコンテキスト。


**命名規則の例 [#i3ab99f7]
-Element.ToPagenameSet
ページ名の集合。順序なし。
-ToPagenameList
ページ名の順序ありリスト。
-ToHTML
HTML（単要素）
-ToWikiText
WikiText。つまり処理前の入力されたデータそのまま。単要素。
-ToDataSet
何かの集合。Element次第。呼び出した方もそれなりに処理。
***[[:i/ビュー別テンプレート]] [#n7f24fa2]
データコンテキストの始まりはリクエスト。その次がビュー。
リクエスト以降同じデータコンテキストが要求されていく。データコンテキストはリクエストからレスポンスまで連鎖するもの。

で、Elementによってはこれが別のメソッドのラッパーだったりしていい。