ページ/要素/UI のバックアップ(No.12)

to your Kindle

目次 †

目次
関連
UI周辺のタグ
機能/UI

UI周辺のタグ †

Array

機能/UI †

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

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

データの保存先指定 †

呼び出し時のパラメーターに「データの保存先」を。
できるだけ多くの機能で。

具体的なページ名なら全利用者が共有する機能になるし、呼び出した利用者の利用者ページにすれば個人用の機能になる。

保存先ページのディレクトリ部分が変わるだけ。

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

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

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

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

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

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

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

→おかしな表示にする。

インライン/ブロック/ページの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つのフォームで異なるアルゴリズムの検索機能を呼び出せるなどが可能に。