目次 † Edit

  1. 目次
  2. 関連
  3. プラグイン周辺のタグ
  4. プラグイン
  5. 実装
    1. 4態
    2. プラグインはオブジェクト
    3. プラグインの展開タイミング
    4. 導入
    5. プラグインは部品
  6. モデリング
    1. Chain of Responsibility
    2. ページ─プラグインはコンポジションに
    3. どのプラグインか
    4. 呼び出し方2種類
      1. 常時有効なプラグイン
      2. トリガーを備えるプラグイン
    5. MVC
    6. データドリブン
    7. ページに記述されたとき、Chain of Responsibilityで
      1. トリガー指定
      2. 実行順序
      3. データの改ざん

関連 † Edit

 

検索:プラグイン

 

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

Array
 

プラグイン † Edit

プラグインとWikiFormatについて。

プラグインを「WikiFormat」と呼ぶ。

実装 † Edit

4態 † Edit

WikiText→オブジェクト（保存される）→HTML→キャッシュ（保存される）
…をプラグインごとに行う。

キャッシュの保存はプラグインごとに。

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

プラグインはオブジェクト † Edit

プラグインをページとコンポジション関係にして、ページのデシリアライズを単純化。

…などは1つのオブジェクトにしたほうが都合が良い。

…が、機能が低下するので却下。
デシリアライズが複雑になる。

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

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

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

導入 † Edit

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

プラグインは部品 † Edit

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

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

モデリング † Edit

Plug-inはネスト可能。
Decorator。

オブジェクトから展開済みテキストを得る。
Plug-inが独自にファイルを作るかも。

  • →ライブラリでサポート
    削除もしやすく。しやすくする以上のことはできない。

書き換え(編集)はPageのテキストと複数ファイルに対して。
直後にオブジェクト群を再生成。

版は？
→クラス定義に(テキストと複数ファイル)を残すこと。
オブジェクトは残さなくて良い(はず)。
差分はとれるか？→取れる。

&ref(): File not found: "Page-Plugin.png" at page ":i/機能";
Plug-inをオブジェクトとして永続化する場合、Pageと一緒にということになる。
動的データはPageが持つテキストからすべて作成可能。
クラス定義ではテキスト1つと複数ファイル。
インスタンスはテキストから複数Plug-in、そのままの複数ファイル+テキストということに。
→テキストからPlug-inを作って足すだけ。

Chain of Responsibility † Edit

プラグインはChain of Responsibility。

クエリーはプラグイン名とページ名を指定するのでなく、やって欲しいことを。
同じクエリーでも導入されているプラグイン次第で別の処理が行われるかも知れない。

WikiEngine自体もChain of Responsibility。
Webアプリは一問一答ばかりなので、これを一問二答/三答にできれば尚可に。

ページ─プラグインはコンポジションに † Edit

どのプラグインか † Edit

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

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

呼び出し方2種類 † Edit

常時有効なプラグイン † Edit

トリガーが内部にある。自動起動。

実装はテンプレートメソッドの集まり。

トリガーを備えるプラグイン † Edit

WikiTextとして記述して使うもの。

両立もできる。

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

遅い→起動時:データドリブン

ページに記述されたとき、Chain of Responsibilityで † Edit

WikiFormatに分類されるものも含めてChain of Responsibility。

ただし、高速化のため1文字程度を各プラグインから提出してもらう。
それらを事前判定に使う。
その判定の後に見込みのあるプラグインを呼んで本判定をしてもらう。

 

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

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

トリガー指定 † Edit

  • 1ページごとに
  • 全ページ処理前に、処理後に
  • 特定モジュールの処理前に、処理後に

…など。

実行順序 † Edit

プラグインの実行順をURLクエリーに書かれている順ということにする。
同じトリガーを使うプラグインが複数ある場合。

データの改ざん † Edit

前のプラグインの出力は次のプラグインに入力される。
クライアントからの入力も書き換え可能。次のプラグインには書き換え後が渡る。

問題は出力と入力のデータ型を統一すること。
文字列か、文字列の集約。
HTMLで書かれたページの断片。