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

to your Kindle

フレームワーク/WikiEngineより

やること
1. フレームワーク/WikiEngine
2. :i/Tokenize対象はNotationText
これから考えること

やること †

フレームワーク/WikiEngine †

†フレームワーク/WikiEngine#be46ac08:『WikiEngineとは』 [#v47ed41a]

利用者　→　フレームワーク/Webアプリケーション
 クライアントアプリとユーザーエージェントの役目。リクエスト。
フレームワーク/Webアプリケーション　→　フレームワーク/WikiEngine
クエリーの解析、セッションの用意など。
†プロトタイピング#d19defef:『フレームワーク間の関係』[?]
フレームワーク/WikiEngine　→　ページと要素
セッションページなどページ/要素のための環境を用意。ページが持つWikiTextからページ/要素の生成。
ページ　→　ページ/要素
 ページでやること。
ページ/要素（各種機能）
各ページ/要素でやること。
…
フレームワーク/WikiEngine　→　フレームワーク/Webアプリケーション　→　利用者
レスポンスをデコレーションしてそれぞれふさわしい形式にして。
†プロトタイピング#d19defef:『フレームワーク間の関係』[?]

:i/Tokenize対象はNotationText †

NotationText解析・ページ/要素構築の仕組みを変更。

これから考えること †

X †

実装案。

連携相手になるページ/要素を指定する方法 †

全てURIで †

参照記法は不要 †

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

API向けパーマリンク †

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

ページ/要素の導入と呼び出す仕組み †

プラグイン †

プラグインの仕組みはフレームワーク/WikiEngineのもの。
最も多いのはページ/要素のプラグイン。

†プラグインは既存クラスのプラグイン版[?]

記法の優先順位 †

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

ページから要素を作る方法 †

記法 †

記法の仕組み †

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

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

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

Notations
:i/ページ/要素[?]を表す記法
AutoLink
自動リンクも記法。動的記法。
Semantics
WikiTextを独占しない／消費しない記法
†検索用テキストを作るならページ要素で[?]
Plains
WikiText中の記法になっていない部分

ページ/要素ができること †

ページ/要素 †

ページ/要素/UI †

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

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

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

:i/要素に書き込む方法 †

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

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

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

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

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

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

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

エラーメッセージにクラス名 †

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

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

簡単なAPI †

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

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

要素のインスタンスID †

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

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

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

プラグインが使えるフック †

フックは不要。要素が動くトリガーは状況に依らない。状況次第なのはそれ以降の要素内の処理。つまり要素次第。

ページのイテレーター †

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

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

機能/APIとは †

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

→ページ/要素/API[?]にページ名変更。

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

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

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

ほか †

:i/フレームワーク/WikiEngineからの出力をレスポンスにする †

ToWikitextはそのまま返す[?] †

ToGenericNotationText()

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

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

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

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

名前の同一視#sa0f0121[?] †

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

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

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

スタイルシートをページから生成 †

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

WikiでWiki自身の設定を。

リクエスト再送はフレームワークで †

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

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

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

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

下位展開 †

ビューの問題。閲覧時以外にもページを扱う場面ならどこでも起こる。

まだ †

ページを扱う仕組み †

ページ
ページ/名前
ページ/内部名[?]
ページ/属性
ページ/裏[?]
履歴
編集/UI
ToDo/ページ削除のUI[?]