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

目次 Edit

関連 Edit

 

検索:プラグイン

 

プラグイン周辺のタグ Edit

Array
 

プラグイン Edit

一般的に「プラグイン」と呼ばれているものと、それを呼び出すための書式(Wiki記法)をまとめて扱う。
→「WikiNotation」と呼ぶ。

インライン/ブロック/ページ 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

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

その他のプラグイン Edit

設計 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を作って足すだけ。

利用者による編集と同じで、ページを更新するときは履歴を作るのが基本。
でも、プラグイン設定プラグイン内の定義)で履歴を作らないことが指示されていれば作らない。

展開は閲覧時 Edit

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

メタシンボルの類も同じ。他のプラグインと同様に。

Chain of Responsibility Edit

プラグインはChain of Responsibility。

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

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

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

ページプラグインはコンポジションに 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など

深さ優先の呼び出し。

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

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

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

 

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

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

トリガー指定 Edit

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

…など。

実行順序 Edit

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

データの改ざん Edit

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

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