目次 †
利用者にとってのページ/要素。
関連 †
検索:UI
UI周辺のタグ †
Arrayプラグイン/UI †
:t/要素 :t/UIより †
プラグインの書式で、属性の記述順は順不同。単位や値で自動判別。
判別不可の場合はプラグインが定義している順に書かれていると解釈する。
AND検索::t/要素 :t/UI
UI/ †
データの保存先指定 †
呼び出し時のパラメーターに「データの保存先」を。
できるだけ多くのプラグインで。
具体的なページ名なら全利用者が共有するプラグインになるし、呼び出した利用者の利用者ページにすれば個人用のプラグインになる。
保存先ページのディレクトリ部分が変わるだけ。
UIからの呼び出し方法2種 †
ブロック要素/インライン要素を区別しない †
使うときにややこしい。
その要素だけの行を作ればブロック要素、それ以外はインライン要素になるように。
→ブロック要素内の要素は全てインライン要素になる。
他、ページに属性を付ける要素も。
違反…ではなくブロックに非対応の要素をブロックにした場合
- 改行を入れてブロック要素とする?
- 何もせず無効化する?
→おかしな表示にする。
インライン/ブロック/ページの3スコープ → ページ/ラインの2スコープ †
ページ定義をプラグインのみで行えば、プラグインの挙動はページ全体に対するものになる。
見出し1つがページ1つに対応するので、見出しとプラグイン名を組み合わせた書式で。
複数行に渡るデータを引数にするプラグインなら、ページ1つを引数ということにしたほうが使いやすい。
ブロック要素とするとブロック開始・終了のキーワード、またはブロック継続のための書式が必要になるので、頭の悪い子には扱えないばかりか批判が出る。
ブロック要素は段落単位で †
ブロック要素を取り入れるなら分かりやすく。
開始・終了を書かずに、段落(空行から空行まで)に。段落のどこに書いても段落全体が影響を受ける。
「Wiki記法」の削減 †
- 貼り付け系記法は不要。URIで判断できるから外部リンクと統合すべき。
何かを貼り付けるときに加工を要するのはアウト。コピー→アプリ切り替え→ペーストだけでも3ステップ。貼り付けだけでも大きな手間なのに。 - コマンド名、単語を要するものは記法未定義のプラグインで使用するだけに。
- 割り当てる記号が足りないならサポート範囲が広すぎるのでは?
使いもしない記法のせいでよく使う記法が書きにくいのはUI設計のアンチパターン。
ネスト †
プラグインからプラグインを使う。
ネストしている場合、中にあるプラグインの出力が外のプラグインに渡る。
外側から解析。()が合わないときは内側にしわ寄せ。
プラグインには個数制限を設けないように †
1つのページに同じものが複数あれば、それらを統合して扱う。
PukiWikiプラグインのtag.incのような使いにくいものはダメ。
プラグインの呼び出し回数は1ページに付き1回のみにする。
システム側で対応。
プラグインの説明はページに †
導入方法、管理方法など。
管理者向けのものは全プラグイン共通のコマンドで。
plugin=tag&cmd=doc
とか。
ユーザー向けの説明はインストール時に作成。
ヘルプページからリンクされる。
手順
- ファイルを置く
- URLクエリーにプラグイン名を入れて、呼び出し
→インストールされる。(仮設定で)
ヘルプもできる。
設定ページができているので、プラグインの情報を集めているページからアクセス。
設定ページを書き換えると設定が有効になる。(ページ更新がトリガー)
ファイルを置く以外は全てWiki上で。
「URLクエリーにプラグイン名を付ける」ために専用フォームを付属するといい。
毎起動時に処理することも出来る †
Wiki上での設定により、毎起動時に呼ばれるようにすることはできる。
:t/設定
フォームプラグイン †
フォームだけのプラグインで利用者からの入力をプラグインに渡すことができる。
通常はURIに含めて、リンクにするとか、プラグイン呼び出し記法でページに埋め込む。
フォームプラグインを使うと、1種類しかないかパラメーターはhidden属性のinputタグ、選択肢のあるパラメーターはリストで選択可能に、値が設定されていないパラメーターはテキストボックスで入力可能…というフォームを作ることができる。
いずれかの方法でプラグイン名を指定すれば、1つのフォームで異なるアルゴリズムの検索プラグインを呼び出せるなどが可能に。