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

to your Kindle

要素(Elements)とそれを利用するフレームワーク/WikiEngineの仕組み。

ページ/要素とは †

機能追加の仕組みと追加されるもの。
記法のプラグインを使う仕組み。
汎用記法か、要素ごとに定義した記法で記述すると機能するようになる。

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

名前付きパラメーター †

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

機能にUsage †

機能に書かれているテキストをヘルプに出す。
マウスポイント時のバルーンやtipsにも出せるようなシンプルな体裁で。
というか、組み込み済みの記法で。

Usage()→組み込み済み記法と汎用記法

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

検索時の同一性評価で、足りない情報を同じページから取得。
時刻だけの表現には同じページにある日付を。同じページに日付だけの表現がないなら日付時刻から日付を流用。

足りないフィールドは同じ（近い）ページから取得。
Wikiなので情報は非定型。補える場合は少ないし重複がある。
→足りない情報を補うための機能ではなく、近い情報を加味する基本的な機能で。

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

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

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

インスタンス †

というか、設定を複数用意可能に。
同じ機能でも設定ごとに異なる記法を当てて、使い分けできるように。

機能側で設定ページをパラメーター化すればいい。
記法の記述で、Notationと設定を抱き合わせにすれば実現可能。
フレームワークでやる必要はない。

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

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

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

3態 †

WikiText→オブジェクト→HTML
…を機能ごとに行う。出力はそのままレスポンスに含める。

記法（設定に依存しない基本的な記法）をHTMLに変換するためのライブラリを用意。
これで他の記法と変換結果を統一。

HTMLのメモ化は機能ごとに。

~~オブジェクトの保存はバージョニングのこと。~~
~~ページの属性次第で保存するかしないかが決まる。~~
~~保存しないのは特殊なページ。~~

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

ページは機能のコンポジション。永続化と復帰を単純化。

リンクは1つのオブジェクトにしたほうが都合が良い。
…が、機能が低下するので却下。
永続化と復帰が複雑になる。

機能の展開タイミング †

ページ特有の解析処理（利用者登録など）の前か後かは機能の実装次第で決まるように。
ページ特有の処理の前に展開すれば展開後のテキストも解析されることになる。

includeのように他のページを取り込む機能を使えば、任意のページを利用者登録ページに取り込んで一括登録できる。その代わり取り込まれるページも管理者権限でしか編集できないようにしなければならない。など利点と欠点がある。

機能の出力はそれ以上処理しないので、自動リンクや埋め込みの展開などは機能側で行なう。
記法（機能呼び出し）のパラメーター部分に記法があっても処理するのは機能。それ以外はページが処理。
これでページ/編集/HTML書き込み[?]の埋め込みと展開を邪魔しないようにできる。
機能の出力はWikiTextではなくHTML。そのままレスポンスの一部になる。

機能の処理のうち共通部分に埋め込みの展開を置いてもいい。
メタシンボルの埋め込みで動的なパラメーター指定ができるが、これを全機能の仕様にしたいので。

入力:WikiText　→

ページ	記法の解釈、オブジェクト化。
機能	埋め込み展開
機能	機能自身の処理と自動リンク（機能次第）

→　出力:HTML

機能は部品 †

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

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

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

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

その他の機能 †

ページ全体
閲覧時展開。内容とページ名
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機能」のような特別な方法で。

どの機能か †

機能使用時の記述は機能を表すキーワードと、機能指定のキーワードで。
1つのキーワードで複数の機能呼び出し可能。
処理できる機能1つが処理する。

処理可能かどうかの判定は機能ごとに優先順位ありで、機能内に優先度を記述しておく。

クラス継承 †

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

記法類は機能に継承されていいように。

使い方2種類 †

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

ls→ページ名リストを生成。パラメーターとしてはページセットを生成。

書かれた場所…コンテキスト、文脈。文脈次第で型が変わる。意味は変わらない。使いにくくなるので。

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

どちらの使われ方でも記法を返す。それが何に埋め込まれるかはフレームワークが決める。

実装はインターフェイス。
イベントハンドラーのようなもの。

ユーザーからのリクエストで呼ばれるだけの機能でも、ページに書かれたときに自身を呼ぶリンクやボタンを生成するようにすれば使いやすくなる。

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

PukiWikiのコマンド型機能のように、ページに書かずに使う場合でもネスト可能に。一時的なページを生成してもいい。

またはデリゲート可能に。最後に呼ぶもの以外はデータコンテキスト。

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

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

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など

深さ優先の呼び出し。

機能を実行時に取得 †

機能をUIからのシステム呼び出し時に取得したい。
管理者が機能のURIを入力して。

システムが機能を取得、インストール。

アンインストールは…
機能と同じ著作者のファイルだけ消す。
他の機能でも使うようなものは除く。
参照数をカウントしておけば（また、カウントし直しが随時できれば）より正確にアンインストールできる。

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

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

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