→WikiNotation[?]
→X/PageElement[?]

「プラグイン/」で始まるページを作成

目次 † Edit

  1. 目次
  2. 関連
  3. プラグイン周辺のタグ
  4. プラグイン
    1. インライン/ブロック/ページ
  5. 実装
    1. プラグインにUsage
    2. 時刻だけ書いたら同じページに書かれている日付を加味
    3. インスタンス
    4. 複数行パラメーターの書き方
    5. 3態
    6. ページがコンポジション
    7. プラグインの展開タイミング
    8. 導入
    9. 導入は「置いて書く」
    10. プラグインは部品
    11. 投稿時展開するものは要らない
    12. その他のプラグイン
  6. 設計
    1. 展開は閲覧時
    2. Chain of Responsibility
    3. ページ─プラグインはコンポジションに
    4. どのプラグインか
    5. クラス継承
    6. 使い方2種類
    7. 使い方が2種類あっても実体は同じ
    8. リクエストからの直接呼び出しでもネスト可能に
    9. URLクエリーは一時的ページ
    10. MVC
    11. 設置

関連 † Edit

 

検索:プラグイン

 

プラグイン周辺のタグ † Edit

Array
 

プラグイン † Edit

呼び方「プラグイン」→「PageElement」に。

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

内部ではWikiNotationはプラグイン呼び出し記法に置き換えられる。
プラグイン呼び出しをするクラスはプラグイン記法だけを扱えればいい。

インライン/ブロック/ページ † Edit

3種類の型。
使われ方と出力の違い。使われ方はUIの範疇なので、プラグインでは出力だけ気にすればいい。

インライン
普通の。どこからどこまでかを指示して書く。1文字単位。
ブロック
1段落（空行と空行の間）を一度に処理。段落のどこかに書けばいい。
ページ
1ページを一度に処理。ページの属性として書く。

使われ方の違いは「どう書くか」だけの違い。
1行ごとに指示を書くか、1ページにまとめて指示するか。

内部では渡されるデータの長さと呼び出される回数が違うだけ。
複数行をまとめて扱う必要のある場合、表などはページやブロックじゃないと。

実装 † Edit

プラグインにUsage † Edit

プラグインに書かれているテキストをヘルプに出す。
バルーンやtipsにも出せるようなシンプルな体裁で。
というか、組み込み済みのWikitextで。

Usage()→組み込み済みWikiText

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

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

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

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

各プラグインはそこにパラメーター履歴を残して置けばいい。

フレームワークではプラグインの呼び出し順を一定にする。上から順に。

インスタンス † Edit

というか、設定を複数用意可能に。
同じプラグインでも設定ごとに異なるWikiNotationを当てて、使い分けできるように。

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

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

複数行をプラグインに渡すには、置き換えと埋め込みページが良さそう。

3態 † Edit

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

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

HTMLのメモ化はプラグインごとに。

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

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

ページはプラグインのコンポジション。永続化と復帰を単純化。

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

プラグインの展開タイミング † Edit

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

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

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

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

入力:WikiText　→

ページWikiNotationの解釈、オブジェクト化。
プラグイン埋め込み展開
プラグイン自身の処理と自動リンク（プラグイン次第）

→　出力:HTML

導入 † Edit

  1. ファイルコピー
    所定のサブディレクトリは1つのプラグイン。
  2. 設定ページ作成
    ページ/名前はフレームワークによって決まっている。

導入は「置いて書く」 † Edit

  1. サーバーにファイルを置く
  2. Wikiに何か書く

これで使えるように。
他に必要なことがあれば、この後にメッセージが見えるように。

プラグインの出力がメッセージになるか、プラグイン一覧かプラグインページにメッセージ出力。

管理者だけが読めるメッセージにしたいときは？
管理者宛の親展メッセージにできればいい。呼ばれるたびに送信。数を制限するならプラグインが自粛。

プラグインは部品 † Edit

プラグインは部品であるべき。
組み合わせる余地が要る。

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

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

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

その他のプラグイン † Edit

設計 † Edit

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

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

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

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

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

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

クラス継承 † Edit

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

記法類はプラグインに継承されていいように。

使い方2種類 † Edit

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

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

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

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

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

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

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

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

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

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

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

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

Wiki上での設定でWikiNotationを変更できるなら、プラグインの追加手順は

  1. プログラムファイルを置く
  2. WikiNotation定義に追加
    の2ステップ。ただし、プラグイン呼び出し用の汎用WikiNotation + プラグイン名で呼び出すならWikiNotation定義は要らない。