目次 † Edit

  1. 目次
  2. 関連
  3. API周辺のタグ
    1. トリガー指定
    2. 実行順序
    3. データの改ざん
    1. フレームワーク/WikiEngineからの呼び出し
    2. APIリファレンスは処理系に付属しているツールで生成
    3. ページのイテレーター
    4. バージョン
    5. トリガー2種類
    6. テスト用コード
    7. インスタンスID
    8. オブジェクト取得API
    9. スクラッチ
 
 

関連 † Edit

 
 

検索:API

 

API周辺のタグ † Edit

Array
 

トリガー指定 † Edit

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

…など。

実行順序 † Edit

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

データの改ざん † Edit

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

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

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

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

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

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

ページのイテレーター † Edit

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

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

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

バージョン † Edit

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

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

トリガー2種類 † Edit

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

テスト用コード † Edit

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

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

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

インスタンスID † Edit

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

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

オブジェクト取得API † Edit

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

スクラッチ † Edit

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