要素間でデータを渡すには Edit

コンストラクターのパラメーター Edit

要素のコンストラクターで使用する入力。フォームとクエリー>記法の順で優先。フォーム/クエリーは記法パラメーター不足のときのものなので。これは要素の設定値のようなもの。

:i/UIを使うページ要素:『パラメーター不足時はリクエストから受け付ける』
:i/プラグイン内でプラグインを呼び出すために

要素独自のAPI Edit

To...の引数など。独自仕様でいい。
引数が独自ならメソッドも独自でいい。
自由に定義。それに依存して自由に呼び出し。

汎用記法でも書き方は同じ。UI=API

ページ/属性(をす要素)との連携 Edit

ページ/属性:『書式』

ページ/属性利用者が書くもの。属性以外にも使える記法で兼用。
ページ/裏なら主属性を要素や要素以外のクラス名にして競合を避けたりできそう。

要素呼び出しにもバージョンが必要 Edit

ページ/要素プラグインバージョン番号。
APIにバージョンを付けるよりも、要素を複数バージョン共存させたほうが実装が単純になる。
呼び出し側がバージョン指定。フレームワークが存在するバージョンのうち、指定された以降で最も近いバージョンと結び付ける。

:i/プラグインAPIバージョンは指定しないのが基本
指定が無ければ最新を呼ぶ。問題があれば管理者がコード内でバージョン指定をすればいい。
基本はバージョン指定をしたほうがいいか/しないほうがいいかは決められない。

利用例 Edit

ページ逆リンクを得て一覧化するときに、同じページ同士の自動リンク数(重複数)を含めて欲しいとき。など。

参考になるかも Edit

:i/機能
ページ/要素機能の実装。

データコンテキスト Edit

データコンテキストフレームワーク/WikiEngineが提供する要素間連携機能:t/汎用記法で実装。ページ/要素が各々任意に実装。フレームワークはインターフェイスだけを提供。
呼び出し側(ネストの外側)要素からの「…が欲しい」という要求。呼び出し側が戻り値のを指定。呼び出される側がそれに応じる。

データアクセス
データコンテキスト
対応するメソッド名をそのまま「コンテキスト指定記法」にしてもいい。HTMLコンテキストも記法の1つに加えて。HTMLコンテキストは記法の外のこと。でもそれを記法内に作りたい時のために用意。
コンテキストは呼び出し側にとっては戻り値の要求。呼び出される側にとっては「自身の持つ情報をどのに変換するか」。

要素が受け入れられるを要求しているので、手を加えてもが合わなくなるだけ。を指定しても実際に反映されるのは要素が対応している場合だけ。それなら、指定せずに要素に全て任せたほうがいい。
→各要素が工夫する。別のパラメーターを受け入れられるようにして、いずれかのが入力されれば正しく結果を返すように。複数のが同時に入力されたときも要素側で工夫して。

変換も同様で、変換要素があったとしても意味ある変換ができるのはデータ提供側の要素自身だけ。
変換用のページ/要素は実装不可能。変換できるのは情報を持つ要素自身だけ。他の要素にはできない。