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

to your Kindle

要素(Elements)とそれを利用するフレームワーク/WikiEngineの仕組み。
機能の実装。ほとんどのプラグインはページ/要素。拡張の要。

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

機能とは †

呼び方「機能」→「PageElement」に。
機能追加の仕組みと追加されるもの。
記法の機能。
汎用の機能呼び出し記法か、機能ごとに定義した記法で記述すると機能するようになる。
~~内部では記法は機能呼び出し記法に置き換えられる。~~
~~機能呼び出しをするクラスは機能記法だけを扱えればいい。~~

名前付きパラメーター †

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

機能にUsage †

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

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

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

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

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

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

インスタンス †

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

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

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

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

3態 †

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

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

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

機能の展開タイミング †

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

入力:WikiText　→

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

機能

埋め込み展開

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

→　出力:HTML

機能とは
名前付きパラメーター
機能にUsage
時刻だけ書いたら同じページに書かれている日付を加味
インスタンス
複数行パラメーターの書き方
3態
ページがコンポジション
機能の展開タイミング

:t/要素より

:t/要素より †

機能は部品 †

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

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

URLクエリー †

:/検索式を使う検索 †

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

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

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

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

:i/レイアウト要素 †

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

未分類 †

その他の機能 †

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

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

プラグインは記法 †

プラグインというクラスは作らない。
記法と同じ扱い。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で定期的に取得。
管理者用の機能。