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