フレームワーク/WikiEngineより

  1. WikiEngineとは
  2. 開発, 実装, API
    1. 記法の優先順位
    2. X
    3. ページ要素間の連携方法
    4. クラス別のセッションデータ
    5. ページのイテレーター
    6. ページに記述されたとき、Chain of Responsibilityで
    7. フレームワーク/エラーメッセージにクラス名
    8. フレームワーク/Webアプリケーション/再送
    9. 簡単なAPI
    10. 要素のインスタンスID
    11. クエリーにどう反応するか
  3. 普段の利用, 閲覧
    1. 下位展開
    2. URLクエリーに置くデータ
    3. ページタイトルにユースケース別接頭辞
    4. ページを扱う仕組み
  4. 編集, 記法, プラグイン
    1. 機能/APIとは
    2. 機能/API/テスト用コード
    3. 記法の仕組み
    4. WikiTextから得られるページ/要素
    5. ページ/要素/UI
    6. プラグイン
    7. フレームワーク/WikiEngine/同一視#sa0f0121[?]
    8. 負荷軽減に編集後の更新処理を分割
    9. フレームワーク/WikiEngine/スタイルシートをページから生成
  5. 全てURIで
    1. 参照記法は不要
    2. API向けパーマリンク
  6. ほか
    1. :t/利用者と:t/アカウントの利用

WikiEngineとは † Edit

ユーザーとページを始めとするページ/要素をつなぐもの。
利用者→フレームワーク/Webアプリケーション→フレームワーク/WikiEngine→ページ→ページ/要素（各種機能）

利用者の認証情報でさらなる情報を引き出せるようにするのも。

開発, 実装, API † Edit

記法の優先順位 † Edit

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

X † Edit

実装案。

ページ要素間の連携方法 † Edit

クラス別のセッションデータ † Edit

セッションをクラス間連携に使用するルール。
フレームワークの中で制御するので、個々の要素は値名と値を用意するだけ。簡単不自由なI/F.

†フレームワーク/WikiEngineでやること:『ページ要素間の連携方法』

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

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

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

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

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

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

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

フレームワーク/エラーメッセージにクラス名 † Edit

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

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

フレームワーク/Webアプリケーション/再送 † Edit

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

簡単なAPI † Edit

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

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

要素のインスタンスID † Edit

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

クエリーにどう反応するか † Edit

要素の協調でリダイレクトをどう行なうか。:t/？

普段の利用, 閲覧 † Edit

下位展開 † Edit

URLクエリーに置くデータ † Edit

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

ページタイトルにユースケース別接頭辞 † Edit

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

ページを扱う仕組み † Edit

編集, 記法, プラグイン † Edit

機能/APIとは † Edit

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

機能/API/テスト用コード † Edit

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

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

記法の仕組み † Edit

:t/機能とその実装である:t/要素、それを呼び出す:t/記法。

†変換ルールはページ内で定義[?]
†記法の書式[?]

WikiTextから得られるページ/要素 † Edit

ページ/要素/UI † Edit

拡張可能な要素のUIとは。
†UIを使うページ要素[?]

要素を呼び出すためのUIは記法。エディターと組み合わせて使う一大機能。
†記法
†汎用記法

プラグイン † Edit

プラグインの仕組みはフレームワーク/WikiEngineのもの。

フレームワーク/WikiEngine/同一視#sa0f0121[?] † Edit

括弧書き記法はビルトインのページ/要素。

負荷軽減に編集後の更新処理を分割 † Edit

検索:永続化システム（検索:永続化クラス）で実装。

フレームワーク/WikiEngine/スタイルシートをページから生成 † Edit

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

WikiでWiki自身の設定を。

全てURIで † Edit

参照記法は不要 † Edit

全てURIで。埋め込みで使えれば参照記法は不要。

API向けパーマリンク † Edit

全てURIで参照するための仕組み。
InterWikiName、InterIncludeでも使うのでUI(=API)。

ほか † Edit

:t/利用者と:t/アカウントの利用 † Edit

†ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク[?]

フレームワークで扱うのはログイン（認証）と、権限（錠と鍵）の整合判定。