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

to your Kindle

機能の実装。ほとんどのプラグインはページ/要素。拡張の要。

ページ/要素を使うためにXというフレームワークがある。
利用者によってページに記述され、ページごと呼び出される。
要素は利用者が入力した情報と、いろいろな機能を併せ持つもの。
- 要素はページに記録された情報をオブジェクト化したもの。
- 要素はいろいろ考えた機能の実装。要素の作り方は自由にしていい。
要素をページ上に配置するために使われるのが記法。
ビルトイン要素は簡易マークアップで。プラグイン要素は汎用記法で。
→ :Done/ページ型／スレッド／データコンテキスト／記法定義をまとめて設計#je7681db[?]
要素はページに記述できるプラグイン。記述方法は→記法。
汎用記法か、管理者が定義した記法で記述すると機能するようになる。
~~記法処理中にどの記法も汎用記法に置き換えられる。~~
→ 意味ない。編集時に記法を再現するので置き換える前のテキストは必要。汎用記法に置き換えたとしてもさらにオブジェクトに置き換えなければならないため何のキャッシュにもならない。

:t/要素より
ページ/要素/

:t/要素より †

URLクエリー †

:/検索式を使う検索 †

利用するユースケースクラスによってはURLクエリーがページと同じ型になる。ページとの違いはデータコンテキストの違いだけ。呼ばれたページに含まれるページ/要素は、URLクエリーからデータを引き出すことになる。

あるユースケースでは、URLクエリー上で一時的なページを作れる。レスポンスにはそのページが載る。複数のページをひとつのレスポンスにまとめたりできる。

いろいろなページ/要素 †

:i/レイアウト要素 †

随時作ればいい。
スタイルを与えるだけのもの。あるいは入口と出口の要素を分けて、出口をテンプレート内に配置。入口はページ本文で後から追加。入口の内容が出口にだけ表示される。

未分類 †

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

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

:i/階層化ページ名がタグなら一覧化しないと[?] †

ページ/要素とは †

:i/ページとは †

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

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

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

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

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

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

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

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

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

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

要素で行う場合でも、:i/レイアウト要素と同じように、HTMLヘッダーやHTTPヘッダーに出力できれば可能。要素から要素を呼ぶことになる。

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

ページ/要素/UI †

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

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

:i/簡単なAPI †

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

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

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

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

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

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

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

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

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

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

性質 †

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

設定はスペースにひとつ。その中に同じ要素のパラメーター違いを用意して、それぞれを別の記法にするのがいい。

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

書き方…記法の問題。改行文字をどう扱うか。

:i/要素3態 †

記法は別になった。要素はオブジェクト。

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

ページに要素を与えると機能になるような設計。
ページが機能を持つので、ページ名が機能名になっていい。

:i/要素は部品 †

要素は組み合わせて使う。
個々が機能を提供しなくてもいい。

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

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

:/ページ全体も要素 †

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

プラグインは作る。要素の元になる上位クラス。
要素のプラグイン版として作るので、プラグインインターフェイスを実装した要素になる。

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

:i/要素はChain of Responsibility †

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

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

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

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

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

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

使われ方 †

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

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

ページ/要素/ †

ページ/要素でやること

ページ/要素/UI