ここで作っているWikiEngineについて。
既存のWikiEngineについては→ tag:解析
現在考案中のWikiEngineについて。
- フレームワーク/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 †
Xのシステム部分。(サイトとしてのWikiは半分が利用者のアイデア次第)
利用者から与えられたデータをページ化して保存するもの。
利用者からの要求に応じてページを切ったり貼ったりしてから見せる。
キーワード:WikiEngine
キーワード:Wiki OR ウィキ
ここで考えているWikiEngineは… †
利用者から与えられたデータをページ化して保存するもの。
利用者からの要求に応じてページを切ったり貼ったり整形してから見せる。
コア部分 †
- WikiNotationを含むテキストをオブジェクト化する
- 個々のオブジェクトから(HTMLなどの)別形式を得る
- 各WikiNotationクラスによる同型オブジェクト間の同一性の評価
検索で使用。類似度を算出。 - オブジェクトの永続化
- プラグインの使用
周辺部分 †
特にWebアプリケーションとしてのWikiに必要なこと。
参考 †
思い付き †
- -
ユーザーとページ/要素をつなぐもの。それとページ/要素の動作環境の提供も。
実装 †
呼び出し順序…
URLクエリーに置くデータ †
URLに付けるデータはネット上で共通のもののみ。
個人領域のデータ、状況に左右されるデータは置かない。
URLはどれもパーマリンクにすること。
というわけで、
- 検索/クエリー
認証について †
利用者認証とID取得はフレームワーク/Webアプリケーション。
利用者IDを利用して、実用的な利用者情報を利用可能にするのはフレームワーク/WikiEngine。
…はURLクエリーに含める。
「次」や「前」という表現は使わない †
新/旧、大/小などにする。
ソート順が分かる表現に。
やること †
WikiEngine/ †
データ変換 †
テキスト→オブジェクト→HTML
オブジェクト→永続オブジェクト
もしWikiFormatやプラグインをまったく使えないWikiEngineを作ったら…
テキストを記録するだけ。
ファイル名とテキストを与えると記録、ファイル名のみならテキストを出力。
これにプラグイン独自のデータと処理を加えて、プラグインごとに違うHTML出力ができるようにする。
中心はプラグインを作るためのAPI。
アカウント †
利用者
派閥 †
派閥[?]
負荷軽減 †
→負荷[?]
編集後の更新処理を分割。
ページを指定していないリクエストでは
…を返す。
というわけで、トップページを見せたいときはトップページを指定したリンクを作り、通常はページを指定しないリンクを使う。
これで、静的なページからでもWebブラウザーの履歴を操作することなく、最後に参照したページに戻れる。
URLクエリーに置くデータ †
URLに付けるデータはネット上で共通のもののみ。
個人領域のデータ、状況に左右されるデータは置かない。
URLはどれもパーマリンクにすること。
というわけで、
- 検索/クエリー
…はURLクエリーに含める。
「次」や「前」という表現は使わない †
新/旧、大/小などにする。
ソート順が分かる表現に。
やること †
データ変換 †
テキスト→オブジェクト→HTML
オブジェクト→永続オブジェクト
もしWikiFormatやプラグインをまったく使えないWikiEngineを作ったら…
テキストを記録するだけ。
ファイル名とテキストを与えると記録、ファイル名のみならテキストを出力。
これにプラグイン独自のデータと処理を加えて、プラグインごとに違うHTML出力ができるようにする。
中心はプラグインを作るためのAPI。
アカウント †
利用者
派閥 †
派閥[?]
負荷軽減 †
→負荷[?]
編集後の更新処理を分割。
設計 †
- ユースケースをモデルに入れる。
- ログインページの次はHTTP_REFERERにあるページ。
- ファイルはFlyweightであるべき。
- オブジェクトモデル上ではinclude.incのような機能を考慮しない。
include.incのような機能はデータコピーで実現。 - アクセスログはページの属性。
- 利用者はページにある情報を元に作られる。
- ページが他のページインスタンス宛に編集クエリーを作る。
- 検索はプラグイン化する。
名称 †
クラス間のつながり †
検索時、オブジェクト間のつながり †
ページがHTML出力する時、オブジェクト間のつながり †
ページとプラグイン †
モデルはページ中心 †
- ページ中心
- MVCのVとCは決まりきっている
Mはページとページに関連するクラス。プラグインにはあるかも知れないし無いかも知れない。
Cはフレームワークと各プラグインにある。
フレームワークが持つVのクラスは1つだけ。それ以外にはプラグインが独自に持つかも知れない。 - 要点はプラグインが持てる可能性
オブジェクトの生成 †
- クラス名とインスタンスの対応はFlyweightFactoryが決める。
"WikiEngine"というクラスについて。
ウィキエンジンを表すクラス。
名前が決まり次第、クラス名も変更。
- ユースケースをモデルに入れる。
- ログインページの次はHTTP_REFERERにあるページ。
- ファイルはFlyweightであるべき。
- オブジェクトモデル上ではinclude.incのような機能を考慮しない。
include.incのような機能はデータコピーで実現。 - アクセスログはページの属性。
- 利用者はページにある情報を元に作られる。
- ページが他のページインスタンス宛に編集クエリーを作る。
- 検索はプラグイン化する。
名称 †
クラス間のつながり †
検索時、オブジェクト間のつながり †
ページがHTML出力する時、オブジェクト間のつながり †
Decoratorパターン。
ページとプラグイン †
ページもプラグインも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つでいい。