実装のための情報。

  1. プロトタイピング
  2. 変換
  3. プラグイン
    1. プラグイン側で定義できるものはクラス定義で
    2. データアクセス…
  4. クラス
    1. 図
  5. フレームワーク間の関係
  6. Wiki、Entry、Side、Revision
  7. エラーレベル
  8. 排他制御
  9. Componentの使い方
  10. ASP.NETを使うなら
  11. 実装からTips作成
  12. Xが呼ばれるまで

プロトタイピング † Edit

あとで。

変換 † Edit

PageによるWikitext→HTML変換

  • Wikitextのオブジェクト化
  • Elementから（HTMLなどの）別形式を得る
    HTMLならrender()というメソッド。

変換は多段階で。

  1. Wikitext->統一記法
    記法の優先度順に検出。
  2. 統一記法→PluginNotationElement
    インスタンス化前に記法の連結を行うための段階。
    連結の実態はパラメーターの連結。ここでコンストラクターに渡すパラメーターが決定する。記法はネスト可能なので構造化しないとパラメーターの終端が分からない。
  3. PluginNotationElement→PageElement
    PageElementはデータアクセスに必要。
  4. PageElement→HTML

プラグイン † Edit

名称「PageElement」または「Element」。「Notation」は記法なのでRegexを使って定義するもの。「プラグイン」は実装の仕方なので使わない。

プラグイン側で定義できるものはクラス定義で † Edit

データアクセス… † Edit

ページ内の表（テーブル）記法の内容を配列かList(Of 配列)×配列かList(List (Of String))×List(Of String)に。
リスト（ol、ul）はList(Of String)に。
LINQでSQLのような扱い方が出来る。

ページに問い合わせ。欲しい型別にAPI用意。

Page.getDictionaryData(notationName)

ページは自身の中に要求された型のデータ（Dictionaryなら定義リスト記法）があれば返す。なければnull。
NotationNameは定義リスト記法に書かれている名前。名前を指定しない場合は同じ型のデータをすべて1つにまとめて返す。

型

プラグインは既存クラスのプラグイン版として作成。

継承をするよりもコードテンプレート

クラス † Edit

→クラス[?]

クラス名は…
View::ユースケース名::リクエスト名、Control::ユースケース名

図 † Edit

クラス図
http://dl.dropbox.com/u/2267619/wiki/wiki/%E3%82%AF%E3%83%A9%E3%82%B9%E5%9B%B3%20%E3%83%97%E3%83%AD%E3%83%88%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B003%20Web%E3%82%A2%E3%83%97%E3%83%AA%E3%83%95%E3%83%AC%E3%83%BC%E3%83%A0%E3%83%AF%E3%83%BC%E3%82%AF%E9%83%A8%E5%88%86.png

クラス図
http://dl.dropbox.com/u/2267619/wiki/wiki/%E3%82%AF%E3%83%A9%E3%82%B9%E5%9B%B3%20%E3%83%97%E3%83%AD%E3%83%88%E3%82%BF%E3%82%A4%E3%83%94%E3%83%B3%E3%82%B003%20X.png

フレームワーク間の関係 † Edit

HTMLを要求するのはフレームワーク/Webアプリケーションのほう。
WebアプリケーションはWikiEngineを3回呼ぶ。

  1. エントリーポイント
  2. フレームワーク/Webアプリケーション
    Xオブジェクトを生成。
  3. フレームワーク/WikiEngine
    Xオブジェクトを作る（だけ）。
  4. フレームワーク/Webアプリケーション
    Xオブジェクトにリクエストを伝える（そのまま渡すのではなく、変数の形で）
  5. フレームワーク/WikiEngine
    自身の状態を変化させる。状態は永続化する。
  6. フレームワーク/Webアプリケーション
    XにHTMLを要求。
  7. フレームワーク/WikiEngine
    HTMLを生成。
  8. フレームワーク/Webアプリケーション
    HTMLにヘッダーを付けてWebページ化。

Wiki、Entry、Side、Revision † Edit

  • Entry（項目）
  • Side（見解）
  • Revision（版）

いずれもPageクラスのインスタンス名。
ただし、実体があるのはRevisionだけ。その名を変えたのがEntry、Side。

WikiはEntryの構造体。
ルートページから始まるツリー構造。

各Entryもそれぞれツリー構造。

つまりツリーの要素からまたツリーが始まる2段ツリー構造。

エラーレベル † Edit

  • 利用者向け情報 Info
    不正なリクエストなど。ページのメッセージ欄に出力。
    X/Error/Info[?]
  • 警告 Warning
    デバッグ用ログ出力と管理者グループ宛メールに出力。
    処理続行。
    X/Error/Warning[?]
  • 致命的エラー Fatal
    処理中断。
    開発時のアサーション違反はエラー、運用中は警告だけ。
    X/Error/Fatal[?]

排他制御 † Edit

更新コマンドのキューイング。
キューと要素の関係。
キュー→ファイル（名前順）
要素→永続化されたCommandオブジェクト。
ファイルロックは…PageFactoryが永続化されたオブジェクトを復帰/保存するときと、オブジェクトが自身の関連ファイル（他のオブジェクトの所有物でないファイル）を操作するときくらい。
モデル系クラスでは自分で自身を書き換える。他のクラスを扱うのはPageFactoryくらい。

Componentの使い方 † Edit

  • WikiEngine（の代表的なクラス）を1つのComponent（MVCセット）にする
    WikiEngine内部ではクラス間はWikiNotationで関連するので。似ているけど別の仕組み。
    UsecaseやRequest、Query（検索/クエリーではない）もWikiEngineの一部。Componentの<<control>>や<<model>>部分になる。
    WikiEngineの全クラスをComponentにしなくていい。フレームワーク/Webアプリケーションと関わりのあるクラスだけComponentを継承。
  • サイトのグローバルナビを1つのComponentにする

ASP.NETを使うなら † Edit

ViewとControllerはASP.NET MVCのもの。
非ASP.NET MVC。Wiki - View(.aspx) - Controller。Viewはマスターページのようなものを1つだけ。
プラグイン無し。ControllerでReadなどを実装。というかControllerがプラグインのようなもの。

フレームワーク/WebアプリケーションはASP.NETと競合するので後回し。
フレームワーク/WikiEngine以上を作る。

実装からTips作成 † Edit

実装からTips作成、よりよいコードのヒント集め。
実装以外にも、アイデア、方式、UIなどでも。

Xが呼ばれるまで † Edit

  1. エントリーポイント
    （毎回最初に実行されるコード）
  2. Usecase
  3. 指定されたUsecase配下の指定されたRequest
  4. （Requestによる）X呼び出し

Request→SubUsecase

プラグインの中にはUsecaseを提供するものも。
ページに埋め込むWikiNotationではなくViewを返す。

X自体がデフォルトのプラグインから呼ばれるようなもの。