フレームワーク/WikiEngineでやることのバックアップ(No.25)

Send to your Kindle

優先順位は表やリスト記法で特定のページに記述。
記述順が優先順。
正規表現→ページ/要素を複数記述。正規表現にもページ/要素にも重複があっていい。そうしたほうが設定しやすいし優先順位があるので解決できる。

クエリー文字列にはよそに貼れるデータだけを。
年月が経っても有効なものを。

ページ/要素のスキャンはVisitorパターン。その中でページ/要素のイテレーター（これもページ/要素）を使っている。
例えば検索にヒットしてページのプレビューテキスト取得に。

ページのイテレーターならPage/Factoryが提供するといい。
いろいろな順番で。

リクエストされたページにある要素は全て呼ばれる。
その中でどのクエリーをどう使うかは要素次第なので、別にChain of Responsibilityでなくてもいい。全ての要素がResponsibility.

ページではなくURLクエリーに記述されたときもChain of Responsibilityではない。Chain（連鎖）はするけど。

Androidのインテントのようなものでもない。送り先を決めてパラメーターを用意。戻り値の型も要求する。

エラーメッセージの書き方。
競合も矛盾もない。

エラーメッセージはエラー対処のためのUIでもある。
検索がサイト間のハブサイト、エラーメッセージはその検索へユーザーを誘導する。

利用者の情報損失を防ぐ。リトライ可能に。使いにくくなるのを防ぐ。

要素（機能の実装）がAPIを提供してもいい。制限しないだけ。サポートもしない。自由。

閲覧時には無印なのがポイント。コピペで再利用しやすくなる。

埋め込み後のページにデータアクセス。
埋め込み前にアクセスできても煩わしいだけ。

WikiでWiki自身の設定を。

簡単不自由なAPIと、面倒自由なAPIの両方を用意。
引数の違い。

例えばページ/要素のコンストラクターを2種類用意。どちらかを定義すれば要素として使えるように。

インストール時に動くか確認。
管理者が改造したときにも使える。運用しやすくなる。

UIは…ページ/要素クラス別のページ（複数のバージョンがある場合は下位ページでも作って）にあるテスト実行ボタンで。
テストが複数定義されていればその数だけボタンを表示するように。リフレクション→UIに反映。
テスト環境をどう作るのか。テスト用コードだけでできる:t/？

getElementById()のようなAPIに必要。