入力フォームも要素として実装。
プロトタイピング/03[?]でやったように、入力フォームも要素として実装。
他の要素と組み合わせて使えば、利用者がその要素のパラメーターを決められるようになる。
フォームはどこ †
フォームはページ/型が「フォーム」のページ。
そこに書いたUI要素がUI化する。フォームコンテキストでの展開。
ページ/型はページ全体を1つの要素に与えるようなもの。これで要素がネストする(2段)のと同じことになる。
ページ/型が違うと? †
UI要素を別の型のページに置くと、コンテキストが変わる。要素は異なる反応をする。要素次第。
フォームはどこ †
でもコンテキストはHTMLコンテキストでいいかも。分ける必要なし。ただページは<form>を生成しなければならないので、ページ/型は分ける必要あり。
送り先 †
送り先は1つ。デフォルトではWiki。よそのサイトを指定できればREST APIは呼べる。どう指定するか??ページ/型ではなくフォーム要素?
クエリーは要素とページが作る。特に加工せずリクエスト化。受け側も複数の要素。1つのリクエストに載せるものの特にまとめたりしない。
ページ/型が違うと? †
リクエストが利用されるまで †
送り先は1つ。デフォルトではWiki。よそのサイトを指定できればREST APIは呼べる。UI要素の中でも特にformを表す要素で送り先指定。
クエリーはUI要素
UI要素の上位には入力を受けるべき要素を置いておく。検索結果一覧を作る要素の「検索ワード」部分をUI要素にするといったようにUI要素を他要素のパラメーターにする。
書き方 †
要素の書き方そのまま。汎用記法で書くだけ。
どこで使うか †
編集UI(クライアント側でエディターを呼び出すもの)をこれで。フォームの前後に何がつけたすなら要素追加か、テンプレートか何かで。
検索(小)もこれで。
検索欄(UI要素使用) &search(&form(&textbox(検索キーワードのデフォルト値)))
自分でHTML型ページに.jsを組み込む方法もある。それよりUI要素のほうが簡単でなければ意味なし。
UI生成までにサービス側のコードを要すならUI要素しかない。
参考: 検索結果だけのUI要素無し &search(検索キーワード)
どちらも利用するときは埋め込みで。管理者が埋め込まれるページをパラメーター指定して作り、他の利用者はそれを埋め込むだけ。パラメーター指定をするのは管理者。
継承 †
ページ/型は属性なので継承可能。
ページを1つ作って、その下位ページをすべてフォームにすることができる。
権限も属性なので、編集制限と抱き合わせにして下位ページに継承できる。