- バックアップ一覧
- ソース を表示
- 機能/API は削除されています。
- 1 (2007-12-30 (日) 02:57:47)
- 2 (2008-02-11 (月) 15:29:16)
- 3 (2009-11-07 (土) 01:16:26)
- 4 (2010-02-27 (土) 20:03:28)
- 5 (2011-01-15 (土) 08:17:44)
- 6 (2011-12-14 (水) 01:29:17)
- 7 (2012-07-30 (月) 11:23:10)
- 8 (2012-09-15 (土) 10:37:10)
- 9 (2012-09-20 (木) 06:45:50)
- 10 (2012-09-20 (木) 07:46:16)
- 11 (2012-09-22 (土) 22:35:35)
- 12 (2013-03-03 (日) 11:10:18)
目次 † 
関連 †
API周辺のタグ †
Array
プラグイン/API †
意味は2つ。
- 内部だけのデータでも指定されていればそれを使う。
- 指定されていないデータだけ内部で作る。
一部でも指定されていないデータは内部で作る。 - データの単位をオブジェクトとすれば判定が単純に。
簡単なAPI †
自由度を制限して、テンプレートにあるRegExpだけと出力HTMLだけ書き換えればいいようなAPIも。
ページに記述されたとき、Chain of Responsibilityで †
WikiNotationに分類されるものも含めてChain of Responsibility。
ただし、高速化のため特定のパラメーター1つをクエリーに含めるようにしておく。
それらを事前判定に使う。
その判定の後に見込みのあるプラグインを呼んで本判定をしてもらう。
トリガー指定 †
…など。
実行順序 †
プラグインの実行順をURLクエリーに書かれている順ということにする。
同じトリガーを使うプラグインが複数ある場合。
データの改ざん †
前のプラグインの出力は次のプラグインに入力される。
クライアントからの入力も書き換え可能。次のプラグインには書き換え後が渡る。
問題は出力と入力のデータ型を統一すること。
文字列か、文字列の集約。
HTMLで書かれたページの断片。
フレームワーク/WikiEngineからの呼び出し †
可能な限り多くの副処理呼び出しで割り込み可能にしたい。
APIに制限は要らない。
→TemplateMethodで。
APIリファレンスは処理系に付属しているツールで生成 †
標準ツールで生成されたテキストを体裁付きでページ化できれば尚可。
ページのイテレーター †
- 全ページを内部名順に/表示名順に
- 章を記述されている順に
…などをPageFactoryのI/Fから。
バージョン †
プラグインでは使うクラスのバージョン番号*1を判定。
想定したものより古いなら停止。実行も展開もしない。
フレームワーク側で実現するように。
**トリガー2種類 [#cc61954e] +検索クエリーとページ1つ入力、スコア出力、ページごとに実行 (ページとスコアの結び付けはフレームワークで行う) +検索クエリー入力 全ページのスコアを加算。検索の始まり・終わりなどで実行される。 RIGHT:[[:t/トリガー]]
テスト用コード †
プラグインにテスト用コードを含めること。
実行環境でのテスト。
管理者からのコマンドで実行される。
前提としているプログラムを使えるか確認。
※全てプラグイン任せ。
インスタンスID †
プラグインはどれもIDを持つ。
同じIDなら設定とデータも同じ。
定義時も参照時もデフォルト値あり。だから指定しなくてもいい。
参照時に未定義のIDを使うとエラーメッセージが出力される。
プラグインの設定ページ ID 設定項目 設定項目 ID 設定項目
オブジェクト取得API †
プラグイン用APIにページ/名前やページ/内部名でページ/内容(というかページオブジェクト)を得るものを。
- WikiTextとして書かれているプラグインオブジェクトについては
呼び出しの引数をハッシュ変数にして。 - ページを最後に編集した利用者と見ている利用者を得るのも。
最初に編集した利用者や…を得るものも。