ToDo/要素間の連携方法 †
†http://wiki.pmint.name/index.php?cmd=read&page=ToDo/機能UIの配置方法&word=パラメーター不足時はリクエストから受け付ける
→ 連携する側要素は利用者からセレクターを指定されて、その要素を呼び出す。あらかじめ要素内に用意されている機能。他の仕組みは、いらない。
- -
入力方法3つ †
†http://wiki.pmint.name/index.php?cmd=read&page=プラグイン内でプラグインを呼び出すために
要素間でデータを渡すには †
コンストラクターのパラメーター †
†データアクセス
要素のコンストラクターで使用する入力。フォームとクエリー>記法の順で優先。フォーム/クエリーは記法パラメーター不足のときのものなので。これは要素の設定値のようなもの。
→ :i/UIを使うページ要素:『パラメーター不足時はリクエストから受け付ける』
→ :i/プラグイン内でプラグインを呼び出すために
データコンテキスト
対応するメソッド名をそのまま「コンテキスト指定記法」にしてもいい。HTMLコンテキストも記法の1つに加えて。
要素独自のAPI †
To...の引数など。独自仕様でいい。
引数が独自ならメソッドも独自でいい。
自由に定義。それに依存して自由に呼び出し。
HTMLコンテキストは記法の外のことだが、それを記法内に作りたい時のために用意。
汎用記法でも書き方は同じ。UI=API
コンテキストは戻り値型の要求でも引数の型でもある。入力可能な型を要求する。
パラメーター(引数)をどう与えるか †
汎用記法での書き方と同じ。UI=API
http://wiki.pmint.name/index.php?cmd=read&page=ページ/属性&word=書式
ページ/属性は利用者が書くもの。
ページ/属性(を表す要素)との連携 †
ページ/属性は利用者が書くもの。属性以外にも使える記法で兼用。
ページ/裏なら主属性を要素や要素以外のクラス名にして競合を避けたりできそう。
要素呼び出しにもバージョンが必要 †
ページ/要素プラグインのバージョン番号。
APIにバージョンを付けるよりも、要素を複数バージョン共存させたほうが実装が単純になる。
呼び出し側がバージョン指定。フレームワークが存在するバージョンのうち、指定された以降で最も近いバージョンと結び付ける。
†:i/プラグインAPIバージョンは指定しないのが基本
指定が無ければ最新版を呼ぶ。問題があれば管理者がコード内でバージョン指定をすればいい。
基本はバージョン指定をしたほうがいいか/しないほうがいいかは決められない。
http://wiki.pmint.name/index.php?cmd=read&page=機能/API&word=引数 パラメータ
利用例 †
ページの逆リンクを得て一覧化するときに、同じページ同士の自動リンク数(重複数)を含めて欲しいとき。など。
参考になるかも †
→ 機能[?]
→ :i/機能
ページ/要素は機能の実装。
コンテキスト †
コンテキストはフレームワーク/WikiEngineが提供する要素間連携機能。
呼び出し側(ネストの外側)要素からの「…が欲しい」という要求。呼び出し側が戻り値の型を指定。呼び出される側がそれに応じる。
→ データアクセス
→ コンテキスト
コンテキストは呼び出し側にとっては戻り値型の要求。呼び出される側にとっては「自身の持つ情報をどの型に変換するか」。
型変換用のページ/要素は実装不可能。型変換できるのは情報を持つ要素自身だけ。他の要素にはできない。