目次 †
利用者にとってのページ/要素。
関連 †
検索:UI
UI周辺のタグ †
Arrayプラグイン/UI †
:t/要素 :t/UIより †
プラグインの書式で、属性の記述順は順不同。単位や値で自動判別。
判別不可の場合はプラグインが定義している順に書かれていると解釈する。
AND検索::t/要素 :t/UI
UI/ †
UIからの呼び出し方法2種 †
ブロック要素/インライン要素を区別しない †
使うときにややこしい。
その要素だけの行を作ればブロック要素、それ以外はインライン要素になるように。
→ブロック要素内の要素は全てインライン要素になる。
他、ページに属性を付ける要素も。
違反…ではなくブロックに非対応の要素をブロックにした場合
- 改行を入れてブロック要素とする?
- 何もせず無効化する?
インライン/ブロック/ページの3スコープ †
ページ定義をプラグインのみにすれば、プラグインの挙動はページ全体に対するものに。
見出し1つがページ1つに対応するので、見出しとプラグイン名を組み合わせた書式で。
複数行に渡るデータを引数にするプラグインなら、ページ1つを引数ということにしたほうが使いやすい。
ブロック要素とするとブロック開始・終了のキーワード、またはブロック継続のための書式が必要になるので、頭の悪い子には扱えないばかりか批判が出る。
ネスト †
プラグインからプラグインを使う。
ネストしている場合、中にあるプラグインの出力が外のプラグインに渡る。
外側から解析。()が合わないときは内側にしわ寄せ。
プラグインには個数制限を設けないように †
1つのページに同じものが複数あれば、それらを統合して扱う。
PukiWikiプラグインのtag.incのような使いにくいものはダメ。
プラグインの呼び出し回数は1ページに付き1回のみにする。
システム側で対応。
プラグインの説明はページに †
導入方法、管理方法など。
管理者向けのものは全プラグイン共通のコマンドで。
plugin=tag&cmd=doc
とか。
ユーザー向けの説明はインストール時に作成。
ヘルプページからリンクされる。
手順
- ファイルを置く
- URLクエリーにプラグイン名を入れて、呼び出し
→インストールされる。(仮設定で)
ヘルプもできる。
設定ページができているので、プラグインの情報を集めているページからアクセス。
設定ページを書き換えると設定が有効になる。(ページ更新がトリガー)
ファイルを置く以外は全てWiki上で。
「URLクエリーにプラグイン名を付ける」ために専用フォームを付属するといい。
毎起動時に処理することも出来る †
Wiki上での設定により、毎起動時に呼ばれるようにすることはできる。
:t/設定