機能の実装。ページ/要素を使うためにXというフレームワークがある。
利用者によってページに記述され、ページごと呼び出される。


## ページ/要素


ページ/要素とはページに記述できるプラグイン。記述方法は→記法
汎用記法か、管理者が定義した記法で記述すると機能するようになる。

記法処理中にどの記法汎用記法に置き換えられる。
要素ユーザーから渡されたNotationTextを返せなければならない。要素を生成する前に何かに置き換えることはできない。


:t/要素より Edit

あとで残りの:t/要素を追加。

ページ/要素とは Edit

:i/ページとは Edit

ページ/要素はデータベーステーブル内のフィールドにあたる。ただし1要素で値1つ(1フィールドの1レコード分)。

ページ/要素/API[?] Edit

要素(機能の実装)がAPIを提供してもいい。制限しないだけ。サポートもしない。自由。

ページ/要素ができること/しなくてもいいこと Edit

:i/リクエスト内のパラメーターと汎用記法のパラメーターは同じ Edit

呼び出され方を区別しなくていい。
データコンテキストの区別はデータコンテキスト名別のTo…メソッドでできるし。

:i/クエリーにどう反応するか Edit

要素の協調でリダイレクトをどう行なうか?

リダイレクト要素ではなくユースケースの役目。問題なし。

要素リダイレクトを指示するなら他の要素の出力を抑えなければならない。協調しないということなので、不可。リダイレクトをするユースケースを呼び出すボタンを用意して、利用者に押してもらう(協調しないユースケースを呼んでもらう)ような方法なら可。

:i/要素の展開タイミング Edit

ページ/要素/UI Edit

拡張可能な要素UIとは。
:i/UIを使うページ要素

要素を呼び出すためのUI記法エディターと組み合わせて使う一大機能。
記法
汎用記法

:i/簡単なAPI Edit

簡単不自由なAPIと、面倒自由なAPIの両方を用意。
引数の違い。

例えばページ/要素のコンストラクターを2種類用意。どちらかを定義すれば要素として使えるように。

ページ/要素/API#vcafaa10[?] Edit

テストコード。
インストール時に動くか確認。
管理者が改造したときにも使える。運用しやすくなる。

UIは…ページ/要素クラス別のページ(複数のバージョンがある場合は下位ページでも作って)にあるテスト実行ボタンで。
テストが複数定義されていればその数だけボタンを表示するように。リフレクション→UIに反映。
テスト環境をどう作るのか。テスト用コードだけでできなければならない。

:i/エラーメッセージにクラス名 Edit

エラーメッセージの書き方。
競合も矛盾もない。

エラーメッセージはエラー対処のためのUIでもある。
検索がサイト間のハブサイト、エラーメッセージはその検索ユーザーを誘導する。

:i/汎用記法で名前付きパラメーター Edit

:i/要素にはUsageを含める Edit

ほか Edit

:i/時刻だけ書いたら同じページに書かれている日付を加味 Edit

:i/投稿時展開する記法は要らない Edit

性質 Edit

:i/設定違いを別記法にするとシンプルに Edit

:i/複数行パラメーターの書き方 Edit

:i/要素3態 Edit

:i/ページは要素のコンポジション Edit

:i/要素は部品 Edit

:i/要素がページに記述されたとき、Chain of Responsibilityで Edit

:i/要素がページに記述されたとき、Chain of Responsibilityで?
要素間/ページ間の依存をなくす。それぞれが独立。連携するなら相手に依存することになる。プラグインが守らなければならないルールが無い代わりに、連携をサポートすることも無い。

:/ページ全体も要素 Edit

:i/プラグイン要素は記法 Edit

:i/要素展開は閲覧時 Edit

:i/要素はChain of Responsibility Edit

:i/ページ──要素間はコンポジションに Edit

:i/要素クラスの継承 Edit

:i/要素の使い方は2種類 Edit

:i/要素に使い方が2種類あっても実体は1つ Edit

:i/要素はリクエストから直接呼び出されてもネスト可能 Edit

:i/要素呼び出しとMVC Edit

利用例 Edit

:i/URLクエリーは一時的ページ Edit

:i/要素を必要なときにインストール Edit

要素/ Edit