- 追加された行はこの色です。
- 削除された行はこの色です。
RIGHT:&tag(フレームワーク,実装,設計,コード,目次);
#br
*目次 [#cc67582c]
#contents
#br
#lsx(new=true);
#br
*関連 [#h79ad87b]
#lsx(tag=フレームワーク,new=true,except=^WikiEngine(/.*)?$)
#lsx(tag=WikiEngine,new=true,except=^WikiEngine(/.*)?$)
[[検索:フレームワーク]] [[検索:WikiEngine]]
*WikiEngine周辺のタグ [#f7e0a45c]
#tag(0,WikiEngine)
*WikiEngineとは [#d78bd282]
RIGHT:[[:t/WikiEngine]]
現在作成中のWikiEngineフレームワーク。
[[キーワード:WikiEngine]]
[[キーワード:Wiki OR ウィキ]]
利用者から与えられたデータをページ化して保存するもの。
利用者からの要求に応じてページを切ったり貼ったりしてから見せる。
**参考 [#d6531d94]
:人力検索はてな|[[http://q.hatena.ne.jp/1186417853>http://q.hatena.ne.jp/1186417853]]
*思い付き [#de986c8a]
*実装 [#y3209a73]
**URLクエリーに置くデータ [#c57c9c46]
URLに付けるデータはネット上で共通のもののみ。
個人領域のデータ、状況に左右されるデータは置かない。
URLはどれもパーマリンクにすること。
というわけで、
-検索/クエリー
…はURLクエリーに含める。
**「次」や「前」という表現は使わない [#f4686b39]
新/旧、大/小などにする。
ソート順が分かる表現に。
RIGHT:[[:t/コンセプト]]
**やること [#idbaff1b]
***データ変換 [#j528038f]
テキスト→オブジェクト→HTML
オブジェクト→永続オブジェクト
もしWikiFormatやプラグインをまったく使えないWikiEngineを作ったら…
テキストを記録するだけ。
ファイル名とテキストを与えると記録、ファイル名のみならテキストを出力。
これにプラグイン独自のデータと処理を加えて、プラグインごとに違うHTML出力ができるようにする。
中心はプラグインを作るためのAPI。
***アカウント [#s0de27cc]
-ログイン、ログアウト
-UIとアカウントと権限設定
-アカウント管理
[[利用者]]
***派閥 [#h3dae9a5]
-ページの複製
-ページの統合
-アカウントとページの結び付け
[[派閥]]
***負荷軽減 [#se24e0c6]
→[[負荷]]
編集後の更新処理を分割。
+クエリー保存、ページ更新のキュー入れ
+%%クエリー保存、ページ更新のキュー入れ%%（衝突時の警告ができなくなってしまうので不可）
+対象となるページの更新、関連するページ更新のキュー入れ
+関連するページの更新（複数回）
RIGHT:[[:t/分割]]
*設計 [#abe64751]
"WikiEngine"というクラスについて。
ウィキエンジンを表すクラス。
名前が決まり次第、クラス名も変更。
-ユースケースをモデルに入れる。
RIGHT:[[:t/クラス]]
-ログインページの次はHTTP_REFERERにあるページ。
-ファイルはFlyweightであるべき。
-オブジェクトモデル上ではinclude.incのような機能を考慮しない。
include.incのような機能はデータコピーで実現。
-アクセスログはページの属性。
-利用者はページにある情報を元に作られる。
-ページが他のページインスタンス宛に編集クエリーを作る。
-検索はプラグイン化する。
**名称 [#v5422904]
-ページ→ページレット
-プラグイン→WikiFormat
**クラス間のつながり [#v3861373]
&ref(:Image/WikiEngine.gif);
**検索時、オブジェクト間のつながり [#y199566b]
&ref(:Image/コラボレーション図 検索.png);
**ページがHTML出力する時、オブジェクト間のつながり [#o3a14de6]
Decoratorパターン。
&ref(:Image/コラボレーション図 HTML出力.png);
**ページとプラグイン [#ued7bf04]
ページもプラグインもDecoratorパターンを構成する。
&ref(:Image/クラス図 ページ.png);
**モデルはページ中心 [#k89eb2e9]
-ページ中心
-MVCのVとCは決まりきっている
Mはページとページに関連するクラス。プラグインにはあるかも知れないし無いかも知れない。
Cはフレームワークと各プラグインにある。
フレームワークが持つVのクラスは1つだけ。それ以外にはプラグインが独自に持つかも知れない。
-要点はプラグインの拡張性（可能性）
--トリガーの種類
～の前/後、他のプラグインと比べたときの優先度、…
--出力箇所の種類
--呼び出し箇所、クライアント側スクリプト部分、ヘッダー、フッター、…
RIGHT:[[:t/クラス]]
**オブジェクトの生成 [#v2749f02]
&ref(:Image/コラボレーション図 オブジェクト生成.png);
-クラス名とインスタンスの対応はFlyweightFactoryが決める。
*コード [#f8ef9511]
[[プロトタイピング]]の実装。
**擬似言語 [#n2a0a895]
[フレームワーク/Webアプリケーションから呼ばれて…]
+セッションデータを受け取る。
+クエリーを処理する。
++ページを作っていろいろして保存したり、ページを開いていろいろする。
ページ作成をFlyweightFactoryに要求して、得られたページにクエリーを渡すだけ。
++ページをHTML化、永続化する。
+HTMLを返す。
**Perl [#e4ce3b1f]
[[code*:362]]
あとはX::Pageの永続化を。
プロトタイプではFlyweightFactoryを実装しない。
X::Pageのインスタンスは1つか2つでいい。
