フレームワーク/WikiEngine のバックアップ(No.8)

to your Kindle

現在考案中のWikiEngineについて。
クラス→X
既存のWikiEngineについては→ tag:解析

目次 †

WikiEngineとは †

Wikiのシステム部分。（サイトとしてのWikiは半分が利用者のアイデアでできている）

キーワード:WikiEngine
キーワード:Wiki OR ウィキ

利用者から与えられたデータを「ページ」化して保存するもの。
利用者からの要求に応じて「ページ」を切ったり貼ったりして整形してから見せる。

参考 †

人力検索はてな: http://q.hatena.ne.jp/1186417853

思い付き †

実装 †

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

URLに付けるデータはネット上で共通のもののみ。
個人領域のデータ、状況に左右されるデータは置かない。
URLはどれもパーマリンクにすること。

というわけで、

検索/クエリー

…はURLクエリーに含める。

「次」や「前」という表現は使わない †

新/旧、大/小などにする。
ソート順が分かる表現に。

負荷軽減 †

→負荷[?]

編集後の更新処理を分割。

~~クエリー保存、ページ更新のキュー入れ~~
衝突時の警告ができなくなってしまうので不可。編集対象ページはすぐに更新、衝突したらそのときのレスポンスで利用者に知らせなければならない。
対象となるページの更新、関連するページ更新のキュー入れ
関連するページの更新（複数回）

ページを指定していないリクエストでは

最後に参照したページ（クライアントにあるデータによる）
デフォルトページ（Wikiの設定による）

…を返す。

というわけで、トップページを見せたいときはトップページを指定したリンクを作り、通常はページを指定しないリンクを使う。
これで、静的なページからでもWebブラウザーの履歴を操作することなく、最後に参照したページに戻れる。

設計 †

ユースケースをモデルに入れる。
:t/クラス[?]
ログインページの次はHTTP_REFERERにあるページ。
ファイルはFlyweightであるべき。
オブジェクトモデル上ではinclude.incのような機能を考慮しない。
include.incのような機能はデータコピーで実現。
アクセスログはページの属性。
利用者はページにある情報を元に作られる。
ページが他のページインスタンス宛に編集クエリーを作る。
検索はプラグイン化する。

名称 †

ページ→ページレット
プラグイン→WikiFormat

クラス間のつながり †

検索時、オブジェクト間のつながり †

ページがHTML出力する時、オブジェクト間のつながり †

ページとプラグイン †

モデルはページ中心 †

ページ中心
MVCのVとCは決まりきっている
Mはページとページに関連するクラス。プラグインにはあるかも知れないし無いかも知れない。
Cはフレームワークと各プラグインにある。
フレームワークが持つVのクラスは1つだけ。それ以外にはプラグインが独自に持つかも知れない。
要点はプラグインが持てる可能性
- トリガーの種類
  〜の前/後、他のプラグインと比べたときの優先度、…
- 出力箇所の種類
- 呼び出し箇所、クライアント側スクリプト部分、ヘッダー、フッター、…

オブジェクトの生成 †

クラス名とインスタンスの対応はFlyweightFactoryが決める。

"WikiEngine"というクラスについて。

ウィキエンジンを表すクラス。
名前が決まり次第、クラス名も変更。

ユースケースをモデルに入れる。
:t/クラス[?]
ログインページの次はHTTP_REFERERにあるページ。
ファイルはFlyweightであるべき。
オブジェクトモデル上ではinclude.incのような機能を考慮しない。
include.incのような機能はデータコピーで実現。
アクセスログはページの属性。
利用者はページにある情報を元に作られる。
ページが他のページインスタンス宛に編集クエリーを作る。
検索はプラグイン化する。

名称 †

ページ→ページレット
プラグイン→WikiFormat

クラス間のつながり †

検索時、オブジェクト間のつながり †

ページがHTML出力する時、オブジェクト間のつながり †

Decoratorパターン。

ページとプラグイン †

ページもプラグインもDecoratorパターンを構成する。

モデルはページ中心 †

ページ中心
MVCのVとCは決まりきっている
Mはページとページに関連するクラス。プラグインにはあるかも知れないし無いかも知れない。
Cはフレームワークと各プラグインにある。
フレームワークが持つVのクラスは1つだけ。それ以外にはプラグインが独自に持つかも知れない。
要点はプラグインの拡張性（可能性）
- トリガーの種類
  ～の前/後、他のプラグインと比べたときの優先度、…
- 出力箇所の種類
- 呼び出し箇所、クライアント側スクリプト部分、ヘッダー、フッター、…

オブジェクトの生成 †

クラス名とインスタンスの対応はFlyweightFactoryが決める。

コード †

プロトタイピング[?]の実装。

擬似言語 †

[フレームワーク/Webアプリケーションから呼ばれて…]

セッションデータを受け取る。
クエリーを処理する。
1. ページを作っていろいろして保存したり、ページを開いていろいろする。
  ページ作成をFlyweightFactoryに要求して、得られたページにクエリーを渡すだけ。
2. ページをHTML化、永続化する。
HTMLを返す。

Perl †

code*:362

あとはX::Pageの永続化を。
プロトタイプではFlyweightFactoryを実装しない。
X::Pageのインスタンスは1つか2つでいい。

プロトタイピング[?]の実装。

擬似言語 †

[フレームワーク/Webアプリケーションから呼ばれて…]

セッションデータを受け取る。
クエリーを処理する。
1. ページを作っていろいろして保存したり、ページを開いていろいろする。
  ページ作成をFlyweightFactoryに要求して、得られたページにクエリーを渡すだけ。
2. ページをHTML化、永続化する。
HTMLを返す。

Perl †

code*:362

あとはX::Pageの永続化を。
プロトタイプではFlyweightFactoryを実装しない。
X::Pageのインスタンスは1つか2つでいい。

やること †

データ変換 †

テキスト→オブジェクト→HTML
オブジェクト→永続オブジェクト

もしWikiFormatやプラグインをまったく使えないWikiEngineを作ったら…
テキストを記録するだけ。
ファイル名とテキストを与えると記録、ファイル名のみならテキストを出力。

これにプラグイン独自のデータと処理を加えて、プラグインごとに違うHTML出力ができるようにする。
中心はプラグインを作るためのAPI。

アカウント †

利用者

派閥 †

ページの複製
ページの統合
アカウントとページの結び付け

派閥[?]

目次 †

関連 †

WikiEngineとは †

参考 †

思い付き †

実装 †

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

「次」や「前」という表現は使わない †

負荷軽減 †

設計 †

名称 †

クラス間のつながり †

検索時、オブジェクト間のつながり †

ページがHTML出力する時、オブジェクト間のつながり †

ページとプラグイン †

モデルはページ中心 †

オブジェクトの生成 †

名称 †

クラス間のつながり †

検索時、オブジェクト間のつながり †

ページがHTML出力する時、オブジェクト間のつながり †

ページとプラグイン †

モデルはページ中心 †

オブジェクトの生成 †

コード †

擬似言語 †

Perl †

擬似言語 †

Perl †

やること †

データ変換 †

アカウント †

派閥 †