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

to your Kindle

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

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

:t/要素より
1. ページ/要素/UI

ページ/要素とは †

ページに記述できるプラグイン。記述方法は→記法。

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

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

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

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

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

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

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

機能の展開タイミング †

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

入力:WikiText　→

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

機能

埋め込み展開

機能自身の処理と自動リンク（機能次第）

→　出力:HTML

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

:t/要素より
1. ページ/要素/UI

:t/要素より †

ページ/要素/UI †

拡張可能な要素のUIとは。
†UIを使うページ要素[?]

URLクエリー †

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

:/検索式を使う検索 †

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

:i/簡単なAPI †

簡単不自由なAPIと、面倒自由なAPIの両方を用意。
引数の違い。
例えばページ/要素のコンストラクターを2種類用意。どちらかを定義すれば要素として使えるように。

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

:i/レイアウト要素 †

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

ページ/要素/API/テスト用コード[?] †

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

未分類 †

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

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

その要素自身の機能で。

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

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

:/HTMLコンテナー †

:/HTML変換の内部処理 †

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

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

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

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

:/ページ全体も要素 †

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

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

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

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

:/機能/APIとは †

:/継承対応要素 †

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

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

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

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

: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 †

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

名前付きパラメーター †

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

要素に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全体で。

その他の要素 †

ページ全体
閲覧時展開。内容とページ名
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