ページ/要素のバックアップの現在との差分(No.29)

to your Kindle

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

ページ/要素
:t/要素より
1. ページ/要素とは
  1. :i/ページとは
  2. ページ/要素/API[?]
2. ページ/要素ができること／しなくてもいいこと
:t/要素より

ページ/要素 †

## ページ/要素

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

:t/要素より †

ページ/要素とは †

ページに記述できるプラグイン。記述方法は→記法。
→ :Done/ページ型／スレッド／データコンテキスト／記法定義まとめ#je7681db

要素はページに記述できるプラグイン。記述方法は→記法。
汎用記法か、管理者が定義した記法で記述すると機能するようになる。
記法処理中にどの記法も汎用記法に置き換えられる。
→ 意味ない。編集時に記法を再現するので置き換える前のテキストは必要。汎用記法に置き換えたとしてもさらにオブジェクトに置き換えなければならないため何のキャッシュにもならない。
→ 解析処理を統一するため。簡易マークアップをプラグイン要素に対応付けられるようになる。

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

:i/ページとは †

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

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

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

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

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

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

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

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

要素の展開タイミング †

ページ特有の解析処理（利用者登録など）の前か後かは要素の実装次第で決まるように。
ページ特有の処理の前に展開すれば展開後のテキストも解析されることになる。
includeのように他のページを取り込む要素を使えば、任意のページを利用者登録ページに取り込んで一括登録できる。その代わり取り込まれるページも管理者権限でしか編集できないようにしなければならない。など利点と欠点がある。
要素の出力はそれ以上処理しないので、自動リンクや埋め込みの展開などは要素側で行なう。
記法（要素呼び出し）のパラメーター部分に記法があっても処理するのは要素。それ以外はページが処理。
これでページ/編集/HTML書き込み[?]の埋め込みと展開を邪魔しないようにできる。
要素の出力はWikiTextではなくHTML。そのままレスポンスの一部になる。
要素の処理のうち共通部分に埋め込みの展開を置いてもいい。
メタシンボルの埋め込みで動的なパラメーター指定ができるが、これを全要素の仕様にしたいので。

入力:WikiText　→

ページ	記法の解釈、オブジェクト化。

要素

埋め込み展開

要素自身の処理と自動リンク（要素次第）

→　出力:HTML

ページ/要素
:t/要素より
1. ページ/要素とは
  1. :i/ページとは
  2. ページ/要素/API[?]
2. ページ/要素ができること／しなくてもいいこと
:t/要素より

ページ/要素/UI †

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

:t/要素より †

URLクエリー †

:i/簡単なAPI †

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

:/検索式を使う検索 †

利用するユースケースクラスによってはURLクエリーがページと同じ型になる。ページとの違いはデータコンテキストの違いだけ。呼ばれたページに含まれるページ/要素は、URLクエリーからデータを引き出すことになる。
例えばページ/要素のコンストラクターを2種類用意。どちらかを定義すれば要素として使えるように。
あるユースケースでは、URLクエリー上で一時的なページを作れる。レスポンスにはそのページが載る。複数のページをひとつのレスポンスにまとめたりできる。

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

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

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

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

:i/レイアウト要素 †

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

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

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

未分類 †

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

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

その要素自身の機能で。

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

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

:/HTMLコンテナー †

:/HTML変換の内部処理 †

:/WikiEngineから機能の呼び出し †

:/データアクセスとは †

:/ブロック要素は段落単位で †

:/プラグインが使えるフック †

:/ページ全体も要素 †

:/ページ属性の型は文字列だけ †

:/機能/API/オブジェクト取得API †

:/機能/API/トリガー2種類 †

:/機能/API/バージョン †

:/機能/APIとは †

:/継承対応要素 †

:/要素からWikiEngineインスタンスを起動可能 †

:/解釈をはさんだ検索 †

:Done/2つ呼ぶ記法 †

:Done/クライアント側にサービス側オブジェクトのProxyを作るには †

:/グローバルオブジェクトを書き換える機能 †

:/セレクターは属性値デコレーションに使えない †

:Done/ページセット取得記法とエレメント取得記法 †

:Done/ページ型／スレッド／データコンテキスト／記法定義まとめ †

:Done/履歴はオブジェクト形式で？ †

:Done/検索はクエリーとページの類似度判定 †

:Done/検索フォーマットは機能を呼ぶか †

:Done/目次に出したいだけの見出しはどう書くか †

:Done/要素がアクティブなWiki／Page／Userを得るには †

:Done/記法の衝突対策 †

:Done/タグとはページか †

:i/APIリファレンスはページ †

:i/LTSV→テーブル †

:i/ToWikitextはそのまま返す †

:i/Tokenize対象はNotationText †

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

:i/UIを使うページ要素 †

:i/UI要素 †

:i/URIは内部型を含むラッパー †

:i/URIを解析して異なるページ要素に渡す仕組み †

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

:i/class属性を付けるならそれごと記法として実装 †

:i/to…は複数指定 †

:i/「Wiki記法」の削減 †

:i/おとなりページ †

:i/ここからの目次 †

:i/なにかのカウンター †

:i/インライン/ブロック/ページの3スコープ → ページ/ラインの2スコープ †

:i/オブジェクトにUIを持たせる †

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

:i/データの保存先指定 †

:i/ハブとして機能する要素 †

:i/ファセットを並べるだけでなく集計もしたい †

:i/ファセット分類 †

:i/ファセット化の対象は専用のメタデータ †

:i/フォーム要素 †

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

:i/プラグイン内でプラグインを呼び出すために †

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

:i/プレビューの集め方 †

:i/プレースホルダー記法 †

:i/プログラムコードを記述するには †

:i/プロセス起動ごとに呼ばれる要素 †

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

:i/ページとは †

:i/ページと他オブジェクトとの関わり合い †

:i/ページと要素は似ている[?] †

:i/ページのイテレーター †

:i/ページは… †

:i/ページは要素でもある †

:i/ページは要素のインターフェイス †

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

:i/ページ内容がオブジェクト構成を表す †

:i/ページ要素のUI †

:i/ページ要素間のつながり[?] †

:i/ページ要素間の連携方法[?] †

:i/metaになる要素 †

:i/ユースケースに即席ページを †

:i/リンクは種別によって見せ方を変える †

:i/ローカライズに関西弁や語尾に何かを付ける方言も †

:i/一行テキスト †

:i/下位展開範囲のスレッドを統合するもの †

:i/何かのカウンター †

:i/全ページの属性を一覧化して書き換え †

:i/名前の同一視 †

:i/型別一覧 †

:i/大抵のHTMLはテンプレートで †

:i/改行は要素 †

:i/文字列からの型変換はExcelでもやっている †

:i/日付に経過日数 †

:i/検索で共起要素を探すには †

:i/検索式は1つの要素で †

:i/検索用テキストを作るならページ要素で †

:i/検索語にスケール指定を [#u3c753 †

名前付きパラメーター †

無名引数を使うならリファレンスやコード補完があるときだけ。
汎用記法では名前付きパラメーターにする。

要素にUsage †

要素に書かれているテキストをヘルプに出す。
マウスポイント時のバルーンやtipsにも出せるようなシンプルな体裁で。
というか、組み込み済みの記法で。
Usage()→ビルトインの記法と汎用記法
→ :i/UIを使うページ要素#g6a26065:『usage』

ほか †

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

検索時の同一性評価で、足りない情報を同じページから取得。
時刻だけの表現には同じページにある日付を。同じページに日付だけの表現がないなら日付時刻から日付を流用。
足りないフィールドは同じ（近い）ページから取得。
Wikiなので情報は非定型。補える場合は少ないし重複がある。
→足りない情報を補うための機能ではなく、近い情報を加味する基本的な機能で。

-------
属性の継承とは違う。
要素が独自に使うデータなので、フレームワークは関わらない。
広い期間で有効なデータ領域を用意するだけ。
→数種類。ページ、プロセス、セッション、アプリケーション。要素向け機能。

各要素はそこにパラメーター履歴を残して置けばいい。

-------
フレームワークでは要素の呼び出し順を一定にする。上から順に。

投稿時展開するものは要らない †

投稿時展開するくらいなら編集時にボタンなどで展開後のテキストを挿入した方がいい。
MediaWikiの~~~~のようなもの。
そういったボタンを使えないクライアントにはただの文字列を提供。編集ページを開いた時点で展開しておく。それをコピペ。量が多くなるのであまり一度に用意できない。

性質 †

インスタンス †

というか、設定を複数用意可能に。
同じ要素でも設定ごとに異なる記法を当てて、使い分けできるように。
要素側で設定ページをパラメーター化すればいい。
記法の記述で、Notationと設定を抱き合わせにすれば実現可能。
フレームワークでやる必要はない。

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

複数行を要素に渡すには、置き換えと埋め込みページが良さそう。

置き換え
```
plugin(l1
l2,p2)
```
WikiCreole式。
改行文字になる表現を使って。要素には改行文字が渡る。
埋め込み
```
plugin({{ページ}})
```
他のページを指すリファレンスを渡す。ページは埋め込みの仕組みを使って展開されてからパラメーターとして要素へ。

3態 †

WikiText→オブジェクト→HTML
…を要素ごとに行う。出力はそのままレスポンスに含める。
記法（設定に依存しない基本的な記法）をHTMLに変換するためのライブラリを用意。
これで他の記法と変換結果を統一。
HTMLのメモ化は要素ごとに。
~~オブジェクトの保存はバージョニングのこと。~~
~~ページの属性次第で保存するかしないかが決まる。~~
~~保存しないのは特殊なページ。~~

ページがコンポジション †

ページは要素のコンポジション。永続化と復帰を単純化。
~~リンクは1つのオブジェクトにしたほうが都合が良い。…が、機能が低下するので却下。永続化と復帰が複雑になる。~~
→リンクはリンク元のオブジェクト。オブジェクト間の関連ではないのでリンク先には影響しない。逆リンクは逆リンクとして別途用意。

要素は部品 †

要素は部品であるべき。
組み合わせる余地が要る。

tag.inc.phpのように固いものや大きなもの、応用の利かないものはまずい。
ツール化しないように。
ツールはページ+要素で。
アプリケーションはWiki全体で。

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

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

その他の要素 †

ページ全体
閲覧時展開。内容とページ名
1ページ内の見出し全て
閲覧時展開。ページ名（省略可）
1ページ内のレベル1見出し全て
閲覧時展開。Webcat Plusに渡せるような。

プラグインは記法 †

プラグインというクラスは作らない。
記法と同じ扱い。X/PageElement[?]
記法はネスト可能。
独自データをページに保存可能。ページに残すので履歴付き。
プラグインのアンインストール方法は？しやすく
しやすくする以上のことはできない。
PageElementをオブジェクトとして永続化する場合、Pageと一緒にということになる。
動的データはPageが持つWikiTextからすべて作成可能。
PageインスタンスはWikiTextから生成したPageElement構造体。
利用者による編集と同じで、ページを更新するときは履歴を作るのが基本。
でも、PageElementの設定（PageElementのコードで定義）で履歴を作らないことが指示されていれば作らない。

展開は閲覧時 †

閲覧時展開。
置き換えない。
HTMLに置き換えてもHTMLエスケープしてしまうので。
ずっと動的に展開。
メタシンボルの類も同じ。他の要素と同様に。

Chain of Responsibility †

ユーザーが直接呼び出すタイプの要素はChain of Responsibility。
クエリーは要素名とページ名を指定するのでなく、やって欲しいことを。
同じクエリーでも導入されている要素次第で別の処理が行われるかも知れないし、いくつの要素が反応するかも変わってくる。管理次第。
これはWikiが正しく構築されていれば正しく動くし、間違っていれば結果（ページ出力）に表れるので分かりやすい。対応付けを厳格にすると設定が難しくなるし、後から付け足した設定で以前の設定が無効になることもあるので、それを回避するのが狙い。
フレームワークもChain of Responsibility。

ページ─要素はコンポジションに †

Notationオブジェクトは書くたびにインスタンス生成。
リファレンスだけを増やしたいときはPukiWikiでの「include機能」のような特別な方法で。

クラス継承 †

組み込み済みクラスを継承して要素化。上位クラスと同じ扱いをされるように。下位クラスを知っているクラスからはそのクラスとして扱われるように。
記法類は要素に継承されていいように。

使い方2種類 †

ページに記述→要素はHTML生成。
別要素のパラメーターとして記述→別要素からパラメーターを渡すよう要求される→純粋なデータを生成。

ls→ページ名リストを生成。パラメーターとしてはページセットを生成。
書かれた場所…コンテキスト、文脈。文脈次第で型が変わる。意味は変わらない。使いにくくなるので。

使い方が2種類あっても実体は同じ †

どちらの使われ方でも記法を返す。それが何に埋め込まれるかはフレームワークが決める。
実装はインターフェイス。
イベントハンドラーのようなもの。
ユーザーからのリクエストで呼ばれるだけの要素でも、ページに書かれたときに自身を呼ぶリンクやボタンを生成するようにすれば使いやすくなる。

リクエストからの直接呼び出しでもネスト可能に †

PukiWikiのコマンド型要素のように、ページに書かずに使う場合でもネスト可能に。一時的なページを生成してもいい。
またはデリゲート可能に。最後に呼ぶもの以外はデータコンテキスト。

MVC †

M: いくつでも。（複数クラス、複数ファイル）
名前などすべて利用者の任意。
V: いくつでも。
Mと同じように任意。
C: 要素のエントリーポイント。
同要素のMとVを呼び出す。
名前に規則あり。フレームワークから呼び出しやすくするため。
C（前）とC（後）がある。

フレームワーク

→

1.C（前）

→

2.M、Vなど

3.子のC（前）

→

4.子のM、子のVなど

5.子のC（後）

→

6.子のM、子のVなど

→

7.C（後）

→

8.M、Vなど

深さ優先の呼び出し。

利用例 †

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

URLクエリーもページと
同じように解析、展開。
使い方も実装も統一できる。

要素を実行時に取得 †

要素をUIからのシステム呼び出し時に取得したい。
管理者が要素のURIを入力して。
システムが要素を取得、インストール。
アンインストールは…
要素と同じ著作者のファイルだけ消す。
他の要素でも使うようなものは除く。
参照数をカウントしておけば（また、カウントし直しが随時できれば）より正確にアンインストールできる。

URIで示された場所に置くもの †

プログラム他、インストールするもの
必要なもの（他者が作ったもの）
インストールの仕方、形式的な書式

URI集を特定のサイトで作り、RSS化。
各Wikiで定期的に取得。
管理者用の機能。

要素/ †

ページ/要素/UI