機能/API のバックアップ(No.11)

to your Kindle

目次 †

目次
関連
API周辺のタグ
機能/API

API周辺のタグ †

Array

機能/API †

意味は2つ。

機能開発のための（WikiEngineが持つ）API
機能が提供するAPI
他の機能が利用するもの。

内部だけのデータでも指定されていればそれを使う。
指定されていないデータだけ内部で作る。
一部でも指定されていないデータは内部で作る。
データの単位をオブジェクトとすれば判定が単純に。

簡単なAPI †

自由度を制限して、テンプレートにあるRegExpだけと出力HTMLだけ書き換えればいいようなAPIも。

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

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

ただし、高速化のため特定のパラメーター1つをクエリーに含めるようにしておく。
それらを事前判定に使う。
その判定の後に見込みのある機能を呼んで本判定をしてもらう。

トリガー指定 †

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

…など。

実行順序 †

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

データの改ざん †

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

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

フレームワーク/WikiEngineからの呼び出し †

可能な限り多くの副処理呼び出しで割り込み可能にしたい。
APIに制限は要らない。
→TemplateMethodで。

APIリファレンスは処理系に付属しているツールで生成 †

標準ツールで生成されたテキストを体裁付きでページ化できれば尚可。

ページのイテレーター †

機能側で使えるように。
ページを出すイテレーターを。

全ページを内部名順に/表示名順に
章を記述されている順に

…などをPageFactoryのI/Fから。

バージョン †

機能では使うクラスのバージョン番号*1を判定。
想定したものより古いなら停止。実行も展開もしない。
フレームワーク側で実現するように。

機能側では自身のデータにバージョンを付けやすいように。それとバージョンの判定→バージョン別処理をしやすいように。

トリガー2種類 †

検索クエリーとページ1つ入力、スコア出力、ページごとに実行
(ページとスコアの結び付けはフレームワークで行う)
検索クエリー入力
全ページのスコアを加算。検索の始まり・終わりなどで実行される。

テスト用コード †

機能にテスト用コードを含めること。
実行環境でのテスト。

管理者からのコマンドで実行される。

前提としているプログラムを使えるか確認。
※全て機能任せ。

インスタンスID †

機能はどれもIDを持つ。
同じIDなら設定とデータも同じ。
定義時も参照時もデフォルト値あり。だから指定しなくてもいい。
参照時に未定義のIDを使うとエラーメッセージが出力される。

機能の設定ページ
  ID
    設定項目
    設定項目
  ID
    設定項目

オブジェクト取得API †

機能用APIにページ/名前やページ/内部名でページ/内容(というかページオブジェクト)を得るものを。

WikiTextとして書かれている機能オブジェクトについては
呼び出しの引数をハッシュ変数にして。
ページを最後に編集した利用者と見ている利用者を得るのも。
最初に編集した利用者や…を得るものも。

スクラッチ †

全ページのある言葉を置き換えたいときに機能を作ってできるように。
必要なのは…

全ページを得るAPI
テスト(…は不可。ページ同士の兼ね合いを見たいこともあるし)
ロールバック
APIで印を付けるとクエリー1つで印の付いた全ページがその印付きの版になる。
ロールバック可能な点にはIDを付けて複数設定可能に。
ログ記録API
ログはページなので、ページに追加できればいい。
機能名を秘密にすれば管理者パスワードは要らないはず。
使って、不要になったら消す。
印付きの機能名にしておけば分かりやすい。一時的な機能を検索するような機能はサポートしない。