目次 † Edit

  1. 目次
  2. 関連
  3. UI周辺のタグ
  4. プラグイン/UI
    1. UIからの呼び出し方法2種
    2. ブロック要素/インライン要素を区別しない
    3. インライン/ブロック/ページの3スコープ → ページ/ラインの2スコープ
    4. ブロック要素は段落単位で
    5. ネスト
    6. プラグインには個数制限を設けないように
    7. プラグインの説明はページに
    8. 毎起動時に処理することも出来る
 
 

関連 † Edit

 
 

検索:UI

 

UI周辺のタグ † Edit

Array
 

プラグイン/UI † Edit

  • 必要なデータが全て存在していればUIを作る必要は無い。
  • 存在しないデータがあればUI作成。
  • 基本はUI作成。UIを作る必要が無いときは自動的に送信するようなUIを作成。

プラグインの書式で、属性の記述順は順不同。単位や値で自動判別。
判別不可の場合はプラグインが定義している順に書かれていると解釈する。

UIからの呼び出し方法2種 † Edit

  1. URLクエリーに処理順で。
    コマンドライン上のパイプと同じ。
  2. ページに書いて。
    それをページの名前と引数で呼び出す。

ブロック要素/インライン要素を区別しない † Edit

使うときにややこしい。
その要素だけの行を作ればブロック要素、それ以外はインライン要素になるように。
→ブロック要素内の要素は全てインライン要素になる。

他、ページに属性を付ける要素も。

違反…ではなくブロックに非対応の要素をブロックにした場合

  • 改行を入れてブロック要素とする？
  • 何もせず無効化する？

インライン/ブロック/ページの3スコープ → ページ/ラインの2スコープ † Edit

ページ定義をプラグインのみで行えば、プラグインの挙動はページ全体に対するものになる。
見出し1つがページ1つに対応するので、見出しとプラグイン名を組み合わせた書式で。

複数行に渡るデータを引数にするプラグインなら、ページ1つを引数ということにしたほうが使いやすい。
ブロック要素とするとブロック開始・終了のキーワード、またはブロック継続のための書式が必要になるので、頭の悪い子には扱えないばかりか批判が出る。

ブロック要素は段落単位で † Edit

ブロック要素を取り入れるなら分かりやすく。
開始・終了を書かずに、段落（空行から空行まで）に。段落のどこに書いても段落全体が影響を受ける。

ネスト † Edit

プラグインからプラグインを使う。

ネストしている場合、中にあるプラグインの出力が外のプラグインに渡る。
外側から解析。()が合わないときは内側にしわ寄せ。

プラグインには個数制限を設けないように † Edit

1つのページに同じものが複数あれば、それらを統合して扱う。
PukiWikiプラグインのtag.incのような使いにくいものはダメ。

プラグインの呼び出し回数は1ページに付き1回のみにする。
システム側で対応。

プラグインの説明はページに † Edit

導入方法、管理方法など。
管理者向けのものは全プラグイン共通のコマンドで。

plugin=tag&cmd=doc

とか。

ユーザー向けの説明はインストール時に作成。
ヘルプページからリンクされる。

手順

  1. ファイルを置く
  2. URLクエリーにプラグイン名を入れて、呼び出し

→インストールされる。(仮設定で)
ヘルプもできる。
設定ページができているので、プラグインの情報を集めているページからアクセス。
設定ページを書き換えると設定が有効になる。(ページ更新がトリガー)

 

ファイルを置く以外は全てWiki上で。

「URLクエリーにプラグイン名を付ける」ために専用フォームを付属するといい。

毎起動時に処理することも出来る † Edit

Wiki上での設定により、毎起動時に呼ばれるようにすることはできる。

:t/設定