フレームワーク/WikiEngineでやることのバックアップの現在との差分(No.61)

to your Kindle

フレームワーク/WikiEngineより
フレームワーク/WikiEngineの実装案。

やること
全体
1. フレームワーク/WikiEngine
  1. フレームワーク/WikiEngine
  2. 流れ
これから考えること
1. X
  1. 実装案
ユースケースを実行するとき
ページ構築時
ページ構築後、要素を呼び出すとき
ページができあがってから
1. ページの組み合わせ
ユースケース別
1. 編集／削除
  1. :Done/ページ削除のUI
あとで
1. フレームワーク/Webアプリケーション/再送
2. :t/利用者と:t/アカウントの利用
1. まだ
  1. 下位展開
  2. ページを扱う仕組み

やること †

全体 †

これから考えること †

X †

実装案。
→ :i/プロトタイピング#d19defef:『フレームワーク間の関係』

実装案 †

ユースケースを実行するとき †

ユースケースは機能拡張の中にもあるクラス。
プラグインの呼び出しに権限判定を付けるならユースケースクラスも必要。
ユースケース内で権限判定をするのでページを扱うということ。ページの扱いはフレームワーク/WikiEngineでやること。
~~ユースケースはビュー（ページ）との関係が強いのでフレームワーク/WebアプリケーションではなくWikiEngineにする。~~フレームワーク/Webアプリケーションでもいい。

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

全てURIで †

参照記法は不要 †

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

:i/ユースケーススコープ †

Controller = Usecase
その中だけで有効なデータ。
→ :i/クラス別のセッションデータ

:/ユースケースチェイン †

→ :/リクエスト時に選べるビュー
リクエストとレスポンスの分離。
…を一般化して複数のユースケースを連鎖させられるように。

認証 †

フレームワーク/Webアプリケーション → フレームワーク/WikiEngine
→ フレームワーク/Webアプリケーションでやること:『フレームワーク/WikiEngine』

API向けパーマリンク †

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

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

→ :i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク
フレームワークで扱うのはログイン（認証）と、権限（錠と鍵）の整合判定。

ページ構築時 †

→ ページ

呼び出すページを特定する †

順不同パス †

→ ページ/名前

ページ/属性の用意 †

→ ページ/属性
属性の継承を行なうのはページの役割。
今のところ:/ページ/裏では継承なし。

ページの復帰／構築 †

記法(notation) → ページ/要素
ページを構築する方法。

:i/名前の同一視#sa0f0121 †

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

ページ名もセレクターで †

記法 †

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

プラグイン †

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

記法の仕組み †

:t/機能とその実装である:t/要素、それを呼び出す:t/記法。
→ :i/変換ルールはページ内で定義
→ :i/記法の書式

記法の優先順位 †

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

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

記法 †

記法の仕組み †

:t/機能とその実装である:t/要素、それを呼び出す:t/記法。
†変換ルールはページ内で定義[?]
†記法の書式[?]

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

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

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

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

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

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

:i/Tokenize対象はNotationText †

NotationText解析・ページ/要素構築の仕組みを変更。
†フレームワーク/WikiEngineでやること:『ページ要素間の連携方法』

ページ構築後、要素を呼び出すとき †

ページ → ページ/要素
ページ/要素 → ページ/要素 → …
→ ページ/要素

要素指定はセレクター／全てURIで †

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

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

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

参照記法は不要 †

全てURIで。埋め込みで使えれば参照記法は不要。
ページではなくURLクエリーに記述されたときもChain of Responsibilityではない。Chain（連鎖）はするけど。
Androidのインテントのようなものでもない。送り先を決めてパラメーターを用意。戻り値の型も要求する。

:i/API向けパーマリンク †

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

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

プラグイン †

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

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

エラーメッセージの書き方。
競合も矛盾もない。
→ :i/プラグインは既存クラスのプラグイン版
エラーメッセージはエラー対処のためのUIでもある。
検索がサイト間のハブサイト、エラーメッセージはその検索へユーザーを誘導する。

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

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

ページ/要素に提供するもの †

フレームワーク/WikiEngineの主な機能は、利用者がページ/要素を扱えるようにすることと、ページ/要素を動作させること。

:i/ページ要素間の連携方法[?] †

簡単なAPI †

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

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

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

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

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

要素のインスタンスID †

:i/要素のインスタンスID †

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

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

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

ページのイテレーター †

ページ/要素のスキャンはVisitorパターン。その中でページ/要素のイテレーター（これもページ/要素）を使っている。

:i/ページのイテレーター †

ページ/要素のスキャンはVisitorパターン。その中でページ/要素のイテレーター（とは言ってもページ/要素の機能）を使っている。
例えば検索にヒットしてページのプレビューテキスト取得に。
ページのイテレーターならPage/Factoryが提供するといい。
いろいろな順番で。
（要素でなく）ページのイテレーターならPage/Factoryが提供するといい。いろいろな順番で。ページ間に構造はないのでページ内容は反映しなくていい。イテレーターになる。

:i/要素がページに記述されたとき、Chain of Responsibilityで？ †

→すべての要素がResponsibilityになる。ネスト構造になっている要素は親要素から子要素が呼ばれるのでChainではある。
ページに記述されてないとき（リクエストのクエリー文字列に記述されたとき）も同じ処理になるよう工夫。
→:i/要素がページに記述されたとき、Chain of Responsibilityで

レンダリング †

ページ → ページ/要素
ページ/要素 → ページ/要素 → …
形式変換／データコンテキスト反映。
フレームワーク/WikiEngine → フレームワーク/Webアプリケーション

機能/APIとは †

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

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

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

:i/ToWikitextはそのまま返す †

ToGenericNotationText()

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

インストール時に動くか確認。
管理者が改造したときにも使える。運用しやすくなる。
UIは…ページ/要素クラス別のページ（複数のバージョンがある場合は下位ページでも作って）にあるテスト実行ボタンで。
テストが複数定義されていればその数だけボタンを表示するように。リフレクション→UIに反映。
テスト環境をどう作るのか。テスト用コードだけでできる:t/？

ページ/要素/UI †

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

ほか †

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

:i/URLクエリーに置くデータ †

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

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

:i/ページタイトルにビュー別接頭辞 †

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

レスポンスのコンテキスト †

ページもページ/要素もコンテキスト別の出力をする。
そのページの出力形式はHTTPリクエストで決める。
→ :/ユースケースチェイン
出力付きユースケースの出力形式をリクエストで指定。
履歴をHTMLで／NotationTextで／印刷用HTMLで…。
実装は…
履歴ビューをページ/要素で構築してからコンテキスト別変換。
差分の＋ーマークもページ/要素で付けてからコンテキスト別変換。