機能/API のバックアップの現在との差分(No.11)

• バックアップ一覧
• ソース を表示
• バックアップ を表示
• 機能/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)

• 追加された行はこの色です。
• 削除された行はこの色です。

RIGHT:&tag(機能,API,フレームワーク,思い付き);

*目次 [#a375eb94]
#contents
#br
#lsx(new=true);
#br

*関連 [#h55f8226]
#related
#br
#lsx(tag=API,new=true,except=^機能/API(/.*)?$)
#br
[[検索:API]]
#br

*API周辺のタグ [#k03b1ff4]
#tag(0,API)
#br
----

*機能/API [#j163d593]
RIGHT:[[:t/API]]

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

--------------------

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


**簡単なAPI [#fd6b9b73]
自由度を制限して、テンプレートにあるRegExpだけと出力HTMLだけ書き換えればいいようなAPIも。
**ページに記述されたとき、Chain of Responsibilityで [#i0036ca7]
記法に分類されるものも含めてChain of Responsibility。
RIGHT:[[:t/Chain of Responsibility]]

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



***トリガー指定 [#q65f12be]
-1ページごとに
-全ページ処理前に、処理後に
-特定モジュールの処理前に、処理後に

…など。


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


***データの改ざん [#k62ae6e0]
前の機能の出力は次の機能に入力される。
クライアントからの入力も書き換え可能。次の機能には書き換え後が渡る。

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

RIGHT:[[:t/？]]
**フレームワーク/WikiEngineからの呼び出し [#h9d19911]
可能な限り多くの副処理呼び出しで割り込み可能にしたい。
APIに制限は要らない。
→TemplateMethodで。
**APIリファレンスは処理系に付属しているツールで生成 [#p872338e]
標準ツールで生成されたテキストを体裁付きでページ化できれば尚可。

RIGHT:[[:t/API]]


**ページのイテレーター [#e8145d18]
機能側で使えるように。
ページを出すイテレーターを。

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

…などをPageFactoryのI/Fから。
**バージョン [#b73e4bc8]
機能では使うクラスのバージョン番号((APIのバージョン。つまり使い方のバージョン))を判定。
想定したものより古いなら停止。実行も展開もしない。
フレームワーク側で実現するように。

----

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


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

RIGHT:[[:t/トリガー]]
**テスト用コード [#mabb9fcd]
機能にテスト用コードを含めること。
実行環境でのテスト。

RIGHT:[[:t/テスト]]

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

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


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

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


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

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

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