フレームワーク/WikiEngineより。

やること Edit

フレームワーク/WikiEngine Edit

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

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

:i/Tokenize対象はNotationText Edit

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

これから考えること Edit

X Edit

実装案。

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

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

全てURIで Edit

参照記法は不要 Edit

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

API向けパーマリンク Edit

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

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

ページページ/要素

プラグイン Edit

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

:i/プラグインは既存クラスのプラグイン版

記法の優先順位 Edit

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

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

ページページ/要素

記法 Edit

記法の仕組み Edit

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

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

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

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

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

ページ/要素 Edit

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

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

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

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

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

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

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

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

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

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

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

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

形式変換 Edit

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

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

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

ToGenericNotationText()

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

リクエストされたページにある要素は全て呼ばれる。その中でどのクエリーをどう使うかは要素次第なので、別にChain of Responsibilityでなくてもいい。全ての要素がResponsibility.
ページではなくURLクエリーに記述されたときもChain of Responsibilityではない。Chain(連鎖)はするけど。
Androidのインテントのようなものでもない。送り先を決めてパラメーターを用意。戻り値のも要求する。


機能使用時の記述は要素を表すキーワードと、要素が指定するキーワードで。1つのキーワードで複数の機能呼び出し可能。Androidのインテントのようなもので。処理できる機能1つが反応する。

処理可能かどうかの判定は機能ごとに優先順位ありで、機能内に優先度を記述しておく。


→リクエストされたページにある要素は全て呼ばれて、URLクエリーを自分なりに解釈する。いくつの要素が反応するかは不明。クエリーに反応できるものが反応する。
宛先要素を書いたり、その要素以外にはクエリーを渡さないといった制限は必要ない。リクエストに含まれるデータは対応する全ての要素に渡る。宛先を書くことで特定要素を確実に反応させるということはあるかも。いずれにせよデータを受ける要素自身が判断。
ネスト構造になっている要素間だけで有効なデータはある。引数と戻り値のようなもの。これは記述の通り。

セレクター全てURIで Edit

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

下位展開 Edit

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

:i/スタイルシートをページから生成 Edit

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

WikiでWiki自身の設定を。

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

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

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

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

:i/負荷軽減に編集後の更新処理を分割[?] Edit

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

認証 Edit

フレームワーク/Webアプリケーションフレームワーク/WikiEngine

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

:i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク

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

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

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

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

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

まだ Edit

ページと要素を扱う仕組み Edit