現在考案中のWikiEngineについて。
クラス設計→X
既存のWikiEngineについては→ tag:解析
- フレームワーク/WikiEngineでやること
- クラス設計→X
- フレームワーク/Webアプリケーションはもう一つのフレームワーク
目次 †
WikiEngineとは †
関連 †
- :/ページを更新できるのは自身だけ
- :/ページ要素間の連携方法
- :/疑似言語とPerlでフレームワーク
- :/要素からWikiEngineインスタンスを起動可能
- :Done/SPAM対策
- :Done/データアクセスでページ要素を更新したい
- :Done/属性の継承法則
- :RenameLog/2009
- :RenameLog/2010
- :RenameLog/2013
- :RenameLog/2014
- :i/クエリーパラメーターはユースケースクラスのもの
- :i/プラグインで独自のシステムを作れるか
- :i/プロトタイピング
- :i/プロトタイピング/01
- :i/ログインはWebフレームワーク、ユーザー管理はWikiフレームワーク
- :i/利用者ページの下位に利用者設定を
- :i/状況依存のページ選択
- :t/Wiki
- API
- X
- fw/Wiki
- テンプレート
- フレームワーク
- フレームワーク/Webアプリケーション
- フレームワーク/Webアプリケーションでやること
- フレームワーク/WikiEngineでやること
- ページ
- ページ/権限
- 下位展開でやること
- 全てURIで
- 利用者
- 権限
検索:フレームワーク 検索:WikiEngine
- -
WikiEngineとは †
wikiのシステム部分。(サイトとしてのWikiは半分が利用者のアイデアでできている)
Xのシステム部分。(サイトとしてのWikiは半分が利用者のアイデア次第)
キーワード:WikiEngine
キーワード:Wiki OR ウィキ
利用者から与えられたデータを「ページ」化して保存するもの。
利用者からの要求に応じて「ページ」を切ったり貼ったり整形してから見せる。
HTML変換の内部処理 †
全記法分、探索
始点・終点の位置を記録。重なりはエラー。
挿入・削除の区別は要らない。対象位置と内容があれば十分。末尾から順次置き換え
位置がテキスト先頭からの距離なので置き換えの影響を受けないよう末尾から。
参考 †
利用者から与えられたデータをページ化して保存するもの。
利用者からの要求に応じてページを切ったり貼ったり整形してから見せる。
思い付き †
実装 †
ページ名にユースケース別接頭辞 †
ブックマークや履歴、ウィンドウタイトルを分かりやすくするために。
閲覧…なし
編集…-
追加…>
…など。
URLクエリーに置くデータ †
URLに付けるデータはネット上で共通のもののみ。
個人領域のデータ、状況に左右されるデータは置かない。
URLはどれもパーマリンクにすること。
というわけで、
- 検索/クエリー
- -
…はURLクエリーに含める。
ユーザーとページ/要素をつなぐもの。それとページ/要素の動作環境の提供も。
呼び出し順序…
「次」や「前」という表現は使わない †
新/旧、大/小などにする。
ソート順が分かる表現に。
認証について †
利用者認証とID取得はフレームワーク/Webアプリケーション。
利用者IDを利用して、実用的な利用者情報を利用可能にするのはフレームワーク/WikiEngine。
負荷軽減 †
→負荷[?]
編集後の更新処理を分割。
クエリー保存、ページ更新のキュー入れ
衝突時の警告ができなくなってしまうので不可。編集対象ページはすぐに更新、衝突したらそのときのレスポンスで利用者に知らせなければならない。- 対象となるページの更新、関連するページ更新のキュー入れ
- 関連するページの更新(複数回)
WikiEngine/ †
→URIとあわない。
WikiNotationの優先順位 †
プラグインにはWikiNotationごとに(プラグインごとではなく)優先順位を定義。
これで複数のNotationに当てはまる場合や、Notationに包含関係がある場合に対応。
WikiEngine側で上書き可能。(Wikiの設定。Notation→プラグインの追加と一緒に定義)
Notationクラス名→優先順位の表を定義。これが無い場合はプラグイン側の定義を使用。
後からでも追加しやすいように優先順位は0以上の小数点数。
設計 †
- ユースケースをクラス化。
- ログインページの次はHTTP_REFERERにあるページ。
- ファイルはFlyweightであるべき。
オブジェクトモデル上ではinclude.incのような機能を考慮しない。
include.incのような機能はデータコピーで実現。- アクセスログはページの属性。
利用者はページにある情報を元に作られる。ページが他のページインスタンス宛に編集クエリーを作る。検索はプラグイン化する。
名称 †
クラス間のつながり †
モデルはページ中心 †
- ページ中心
- MVCのVとCは決まりきっている
Mはページとページに関連するクラス。
Cはフレームワークと各プラグインにある。
フレームワークが持つVのクラスは1つか2つだけ。(PC/Mobile)。それ以外にはプラグインが独自に持つかも知れない。 - 要点はプラグインが持つ拡張性
オブジェクトの生成 †
- クラス名とインスタンスの対応はFlyweightFactoryが決める。
"WikiEngine"というクラスについて。
ウィキエンジンを表すクラス。
名前が決まり次第、クラス名も変更。
- ユースケースをモデルに入れる。
- ログインページの次はHTTP_REFERERにあるページ。
- ファイルはFlyweightであるべき。
- オブジェクトモデル上ではinclude.incのような機能を考慮しない。
include.incのような機能はデータコピーで実現。 - アクセスログはページの属性。
- 利用者はページにある情報を元に作られる。
- ページが他のページインスタンス宛に編集クエリーを作る。
- 検索はプラグイン化する。
名称 †
クラス間のつながり †
ページとプラグイン †
ページもプラグインもDecoratorパターンを構成する。
モデルはページ中心 †
- ページ中心
- MVCのVとCは決まりきっている
Mはページとページに関連するクラス。プラグインにはあるかも知れないし無いかも知れない。
Cはフレームワークと各プラグインにある。
フレームワークが持つVのクラスは1つだけ。それ以外にはプラグインが独自に持つかも知れない。 - 要点はプラグインの拡張性(可能性)
オブジェクトの生成 †
- クラス名とインスタンスの対応はFlyweightFactoryが決める。
コード †
プロトタイピング[?]の実装。
擬似言語 †
[フレームワーク/Webアプリケーションから呼ばれて…]
- セッションデータを受け取る。
- クエリーを処理する。
- HTMLを返す。
Perl †
code*:362
あとはX::Pageの永続化を。
プロトタイプではFlyweightFactoryを実装しない。
X::Pageのインスタンスは1つか2つでいい。
プロトタイピング[?]の実装。
擬似言語 †
[フレームワーク/Webアプリケーションから呼ばれて…]
- セッションデータを受け取る。
- クエリーを処理する。
- HTMLを返す。
Perl †
code*:362
あとはX::Pageの永続化を。
プロトタイプではFlyweightFactoryを実装しない。
X::Pageのインスタンスは1つか2つでいい。
やること †
データ変換 †
テキスト→オブジェクト→HTML
オブジェクト→永続オブジェクト
もしWikiNotationやプラグインをまったく使えないWikiEngineを作ったら…
テキストを記録するだけ。
ファイル名とテキストを与えると記録、ファイル名のみならテキストを出力。
これにプラグイン独自のデータと処理を加えて、プラグインごとに違うHTML出力ができるようにする。
中心はプラグインを作るためのAPI。
アカウント †
利用者
派閥 †
派閥[?]