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

目次 † Edit

  1. 目次
  2. 関連
  3. プラグイン周辺のタグ
  4. プラグイン
    1. インライン/ブロック/ページ
  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

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

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

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

内部では渡されるデータの長さと呼び出される回数が違うだけ。
複数行をまとめて扱う必要のある場合、表などはページやブロックじゃないと。
CSV形式の表を貼り付けるにもページやブロックで表になるよう指示。テキスト加工が要らない。

実装 † 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

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

どのプラグインか † 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で書かれたページの断片。