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

  1. ページ/要素とは
    1. ページ/要素/API[?]
  2. ページ/要素ができること／しなくてもいいこと
    1. :i/リクエスト内のパラメーターと汎用記法のパラメーターは同じ
    2. :i/クエリーにどう反応するか
    3. 機能の展開タイミング
    4. ページ/要素/UI
    5. :i/簡単なAPI
    6. ページ/要素/API/テスト用コード[?]
    7. :i/エラーメッセージにクラス名
    8. 名前付きパラメーター
    9. 要素にUsage
  3. ほか
    1. 時刻だけ書いたら同じページに書かれている日付を加味
    2. 投稿時展開するものは要らない
  4. 性質
    1. インスタンス
    2. 複数行パラメーターの書き方
    3. 3態
    4. ページがコンポジション
    5. 機能は部品
    6. その他の要素
    7. プラグインは記法
    8. 展開は閲覧時
    9. Chain of Responsibility
    10. ページ─機能はコンポジションに
    11. クラス継承
    12. 使い方2種類
    13. 使い方が2種類あっても実体は同じ
    14. リクエストからの直接呼び出しでもネスト可能に
    15. MVC
  5. 利用例
    1. URLクエリーは一時的ページ
  6. 機能を実行時に取得
    1. URIで示された場所に置くもの
  7. 要素/

ページ/要素とは † Edit

ページに記述できるプラグイン。記述方法は→記法。
汎用記法か、管理者が定義した記法で記述すると機能するようになる。

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

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

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

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

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

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

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

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

機能の展開タイミング † Edit

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

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

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

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

入力:WikiText　→

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

→　出力:HTML

ページ/要素/UI † Edit

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

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

:i/簡単なAPI † Edit

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

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

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

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

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

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

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

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

名前付きパラメーター † Edit

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

要素にUsage † Edit

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

Usage()→ビルトインの記法と汎用記法

→ :i/UIを使うページ要素#g6a26065:『usage』

ほか † Edit

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

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

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

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

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

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

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

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

性質 † Edit

インスタンス † Edit

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

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

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

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

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

3態 † Edit

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

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

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

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

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

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

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

機能は部品 † Edit

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

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

その他の要素 † Edit

プラグインは記法 † Edit

プラグインというクラスは作らない。
記法と同じ扱い。X/PageElement[?]

記法はネスト可能。
独自データをページに保存可能。ページに残すので履歴付き。

プラグインのアンインストール方法は？しやすく
しやすくする以上のことはできない。

PageElementをオブジェクトとして永続化する場合、Pageと一緒にということになる。
動的データはPageが持つWikiTextからすべて作成可能。
PageインスタンスはWikiTextから生成したPageElement構造体。

利用者による編集と同じで、ページを更新するときは履歴を作るのが基本。
でも、PageElementの設定（PageElementのコードで定義）で履歴を作らないことが指示されていれば作らない。

展開は閲覧時 † Edit

閲覧時展開。
置き換えない。
HTMLに置き換えてもHTMLエスケープしてしまうので。
ずっと動的に展開。

メタシンボルの類も同じ。他の機能と同様に。

Chain of Responsibility † Edit

ユーザーが直接呼び出すタイプの機能はChain of Responsibility。

クエリーは機能名とページ名を指定するのでなく、やって欲しいことを。
同じクエリーでも導入されている機能次第で別の処理が行われるかも知れないし、いくつの機能が反応するかも変わってくる。管理次第。

これはWikiが正しく構築されていれば正しく動くし、間違っていれば結果（ページ出力）に表れるので分かりやすい。対応付けを厳格にすると設定が難しくなるし、後から付け足した設定で以前の設定が無効になることもあるので、それを回避するのが狙い。

フレームワークもChain of Responsibility。

ページ─機能はコンポジションに † Edit

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

クラス継承 † Edit

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

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

使い方2種類 † Edit

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

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

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

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

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

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

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

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

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

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

MVC † Edit

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

深さ優先の呼び出し。

利用例 † Edit

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

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

機能を実行時に取得 † Edit

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

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

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

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

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

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

要素/ † Edit