- 追加された行はこの色です。
- 削除された行はこの色です。
RIGHT:&tag(プラグイン,フレームワーク,目次);
''「プラグイン/」で始まるページを作成''
#lookup(プラグイン/,* 新規作成 *);
*目次 [#l2546537]
#contents
-プラグインの仕組みについて
#lsx(prefix=プラグイン/,tag=プラグイン^フレームワーク,new=true,sort=reading)
-「こんなプラグインがあったらいいな」
#lsx(prefix=プラグイン/,tag=プラグイン-フレームワーク,new=true,sort=reading)
#br
*関連 [#g66ba238]
//#related
//#br
#lsx(tag=プラグイン,new=true,except=^プラグイン(/.*)?$)
#br
[[検索:プラグイン]]
#br
*プラグイン周辺のタグ [#d7920ddf]
#tag(0,プラグイン)
#br
----
*プラグイン [#gf905b0e]
RIGHT:[[:t/プラグイン]]
プラグインとWikiFormatについて。
プラグインを「WikiFormat」と呼ぶ。
**インライン/ブロック/ページ [#b5d3f668]
3種類の型。
使われ方と出力の違い。使われ方はUIの範疇なので、プラグインでは出力だけ気にすればいい。
:インライン|普通の。どこからどこまでかを指示して書く。1文字単位。
:ブロック|1段落（空行と空行の間）を一度に処理。段落のどこかに書けばいい。
:ページ|1ページを一度に処理。ページの属性として書く。
使われ方の違いは「どう書くか」だけの違い。
1行ごとに指示を書くか、1ページにまとめて指示するか。
内部では渡されるデータの長さと呼び出される回数が違うだけ。
複数行をまとめて扱う必要のある場合、表などはページやブロックじゃないと。
CSV形式の表を貼り付けるにもページやブロックで表になるよう指示。テキスト加工が要らない。
*実装 [#g89232c6]
**4態 [#xaf55508]
WikiText→オブジェクト（保存される）→HTML→キャッシュ（保存される）
…をプラグインごとに行う。
RIGHT:[[:t/永続化]]
キャッシュの保存はプラグインごとに。
オブジェクトの保存はバージョニングのこと。
ページの属性次第で保存するかしないかが決まる。
保存しないのは特殊なページ。
**プラグインはオブジェクト [#tdc9b3bd]
プラグインをページとコンポジション関係にして、ページのデシリアライズを単純化。
-章
-リンク
…などは1つのオブジェクトにしたほうが都合が良い。
…が、機能が低下するので却下。
デシリアライズが複雑になる。
RIGHT:[[:t/？]]
**プラグインの展開タイミング [#s5e07f71]
ページ特有の解析処理（利用者登録など）の前か後かはプラグインの実装次第で決まるように。
ページ特有の処理の前に展開すれば展開後のテキストも解析されることになる。
includeのように他のページを取り込むプラグインを使えば、任意のページを利用者登録ページに取り込んで一括登録できる。その代わり取り込まれるページも管理者権限でしか編集できないようにしなければならない。など利点と欠点がある。
**導入 [#iedc8cf8]
+ファイルコピー
所定のサブディレクトリは1つのプラグイン。
+設定ページ作成
ページ/名前はフレームワークによって決まっている。
RIGHT:[[:t/設定]] [[:t/組み立て]]
**プラグインは部品 [#e9dcf7f2]
プラグインは部品であるべき。
組み合わせる余地が要る。
-tag.inc.phpのように固いものや大きなもの、応用の利かないものはまずい。
-ツール化しないように。
ツールはページ+プラグインで。
アプリケーションはWiki全体で。
*設計 [#qb4c744b]
Plug-inはネスト可能。
Decorator。
オブジェクトから''展開済み''テキストを得る。
Plug-inが独自にファイルを作るかも。
-→ライブラリでサポート
削除も''しやすく''。しやすくする以上のことはできない。
書き換え(編集)はPageのテキストと複数ファイルに対して。
直後にオブジェクト群を''再生成''。
版は？
→クラス定義に(テキストと複数ファイル)を残すこと。
オブジェクトは残さなくて良い(はず)。
差分はとれるか？→取れる。
&ref(Page-Plugin.png);
Plug-inをオブジェクトとして永続化する場合、Pageと一緒にということになる。
動的データはPageが持つテキストからすべて作成可能。
クラス定義ではテキスト1つと複数ファイル。
インスタンスはテキストから複数Plug-in、そのままの複数ファイル+テキストということに。
→テキストからPlug-inを作って足すだけ。
利用者による編集と同じで、ページを更新するときは履歴を作るのが基本。
でも、プラグインの設定（プラグイン内の定義）で履歴を作らないことが指示されていれば作らない。
**展開は参照時 [#vcaee641]
置き換えない。
ずっと動的に展開。
**Chain of Responsibility [#sac8e7d3]
プラグインはChain of Responsibility。
RIGHT:[[:t/Chain of Responsibility]]
クエリーはプラグイン名とページ名を指定するのでなく、やって欲しいことを。
同じクエリーでも導入されているプラグイン次第で別の処理が行われるかも知れない。
WikiEngine自体もChain of Responsibility。
Webアプリは一問一答ばかりなので、これを一問二答/三答にできれば尚可に。
**ページ─プラグインはコンポジションに [#g11dba69]
RIGHT:[[:t/クラス]]
Notationオブジェクトは書くたびにインスタンス生成。
リファレンスだけを増やしたいときはPukiWikiでの「includeプラグイン」のような特別な方法で。
**どのプラグインか [#x8e5fd88]
プラグイン使用時の記述はプラグインを表すキーワードと、プラグイン指定のキーワードで。
1つのキーワードで複数のプラグイン呼び出し可能。
処理できるプラグイン1つが処理する。
RIGHT:[[:t/Chain of Responsibility]]
処理可能かどうかの判定はプラグインごとに優先順位ありで、プラグイン内に優先度を記述しておく。
**呼び出し方2種類 [#dd4bffa7]
***常時有効なプラグイン [#zcefdf22]
トリガーが内部にある。自動起動。
実装はテンプレートメソッドの集まり。
***トリガーを備えるプラグイン [#ne0445ce]
WikiTextとして記述して使うもの。
両立もできる。
**MVC [#k8e5528f]
:M|いくつでも。（複数クラス、複数ファイル）
名前などすべて利用者の任意。
:V|いくつでも。
Mと同じように任意。
:C|プラグインのエントリーポイント。
同プラグインのMとVを呼び出す。
名前に規則あり。フレームワークから呼び出しやすくするため。
C（前）とC（後）がある。
|フレームワーク|CENTER:→|1.C（前）|CENTER:→|2.M、Vなど|||
|~|>|>|CENTER:→|3.子のC（前）|CENTER:→|4.子のM、子のVなど|
|~|>|>|CENTER:→|5.子のC（後）|CENTER:→|6.子のM、子のVなど|
|~|CENTER:→|7.C（後）|CENTER:→|8.M、Vなど|||
深さ優先の呼び出し。
**データドリブン [#cebaa423]
[[遅い→起動時:データドリブン]]
**ページに記述されたとき、Chain of Responsibilityで [#i0036ca7]
WikiFormatに分類されるものも含めてChain of Responsibility。
RIGHT:[[:t/Chain of Responsibility]]
ただし、高速化のため1文字程度を各プラグインから提出してもらう。
それらを事前判定に使う。
その判定の後に見込みのあるプラグインを呼んで本判定をしてもらう。
#br
Wiki上での設定でWikiFormatを変更できるなら、プラグインの追加手順は
+プログラムファイルを置く
+WikiFormat定義に追加
の2ステップ。ただし、プラグイン呼び出し用のWikiFormat + プラグイン名で呼び出すならWikiFormat定義は要らない。
***トリガー指定 [#q65f12be]
-1ページごとに
-全ページ処理前に、処理後に
-特定モジュールの処理前に、処理後に
…など。
***実行順序 [#pca346f2]
プラグインの実行順をURLクエリーに書かれている順ということにする。
同じトリガーを使うプラグインが複数ある場合。
***データの改ざん [#k62ae6e0]
前のプラグインの出力は次のプラグインに入力される。
クライアントからの入力も書き換え可能。次のプラグインには書き換え後が渡る。
問題は出力と入力のデータ型を統一すること。
文字列か、文字列の集約。
HTMLで書かれたページの断片。
RIGHT:[[:t/？]]
