:i/プロトタイピング のバックアップの現在との差分(No.45)

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• バックアップ を表示
• :i/プロトタイピング へ行く。

• プラグインの仕組み
• 代表と投票
  あとで。ページのデータとその設定方法。
• 自動リンクとメタページ
  あとで。投稿時の処理。
• ページ/章
  あとで。投稿時の処理。
• 利用者 User
  ページの一種。ただしフレームワークから直接、利用者の情報として利用。
• 構築 クラスなし
  設定をページに記録すること。
• 見解と投票 Pageで
• データアクセス
  テーブル記法も必要。

変換 †

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

プロトタイピング/05 †

• ページの永続化と復帰
  → フレームワーク/WikiEngine
  ページ/名前が必要。
• ページ/名前
  X/Pages/Name
  外部名4区分と内部名、順不同パス（4区分中の"Entry"）
• ビューとテンプレート
  WikiEngineレベルでのビュー。
  ページ/属性が必要。
• ページ/属性
  属性の継承
  権限の継承
  データアクセスとデータコンテキスト（属性コンテキスト）
  X/Elementが必要。
• 下位展開
• プレビューモード
  セッションが必要。
• セッション
  → フレームワーク/Webアプリケーション
  認証が必要。
• 認証
• X/Element
  全てURIで、セレクター（参照記法）
  • Tokenize
  • 汎用記法、見出しに自動リンク
• :i/プロトタイピング/p05

プロトタイプ05+04+03 †

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

プラグイン †

• プラグイン/APIとデータアクセス
  Pluginインターフェイスを実装したクラス。
  Wiki上の設定項目にプラグインクラス名を追加すれば呼ばれるようになる。

fw/Web †

• Notation（Regex）のデフォルトはプラグイン内部で定義。Wiki上で再定義されていればそれを使うように。
• 連結するか否か(bool)
• Notationクラス名

クラス構成 †

Page.getDictionaryData(notationName)

• Dictionary
  定義リスト記法
• List
  Ol、Ul記法
• Listと配列か、List×List
  テーブル記法
  :t/汎用記法で:t/埋め込み機能を呼び出して権限情報を表示。
  ページとその属性名を全て:t/URIで指定・参照・ページ上にレンダリング。

下位展開 †

• -
  対象になるページは:t/順不同な:t/名前での下位に位置するページ。

• Usecaseプラグイン
  Plugin/Usecaseを実装。
  SubUsecaseも使うならクラス名自由。フレームワークは関わらないので。リクエストの任意のパラメーターを使っていい。
• Notationプラグイン
  Plugin/Notationを実装。
  ページ間の:t/リンクも下位展開に対応する必要がある。
  まとめられたページは:t/見出しとして表示されるので、リンク先もそこへつなげなければならない。

• 下位展開
  このシステムはページが他のページを含むツリー構造になっている。1つのページに含まれるページ階層を深い階層まで一括表示。
• 下位展開を利用した自動リンク先
  深い階層のページは浅い階層の一部（見出し）として表示されるので、素直にはリンクしない。浅いページ/深いページ[?]を、浅いページ#深いページへのリンクに。
• プレビューモード
  編集プレビュー中に他のページを開いて、編集の影響を見ることが出来る。「仮の未来」を見る機能。
• タイムマシンモード
  過去のある時点でのWikiを再現。「実在した過去」を見る機能。
• アクセス制御
  アクセスコントロール。ページ側に「錠」となる属性、ユーザー側に「鍵」となる属性を与えて随時適合するかどうか判定。適合することを各ユースケースの事前条件に。
• リンク一覧
  内部リンク（同一Wiki内リンク）のリンク先一覧。リンクの属性「関連名」でフィルタリング。これで「あるユーザーが閲覧できるページ一覧」と「あるページを閲覧できるユーザー一覧」を生成。
  記法は特に考えず#links(リンク先のほう|リンク対象テキストのほう|全部)

• X(Wiki)
  フレームワーク/WebアプリケーションのComponentにあたる。

そのほか †

• multi-gram
  自動リンク処理で行なっていた”bi-gramを使ったページ名探索”。連続する2文字をインデックス化していたが、数字列では1つのキーに集まり過ぎ、漢字を使う単語では分散し過ぎだったので、文字種により0文字から3文字を使うよう変更。

• ページ作成フォーム記法
  新規ページ作成の入力欄生成。入力受け付け、ページ生成。
  とりあえず #newpage()
  ［Notationsにクラス作成］
• 自動リンクの下位展開対応［Autolink］

  /ページ名#セクションID

  
  リンク対象文字列が /セクション名/ページB/ページA ならリンク先は /ページA/ページB#セクションID

  /ページ名#セクションIDでもリンク対象になるように。リンク先をコピペしてもリンクするように。

• ページ名を4区分に［Pagename］
  Wiki, Entry, Side, Revision
  • 代表
    4区分それぞれに補完ルールがある
    Wiki
    Entry
    Side
    Revision
  • 内部名、メジャーIDになるのはEntryだけ（ユーザーが指定するので）
    ［Pagename］
    PageFactoryで扱うのは内部名
  • 下位展開
    セクション記法（見出し記法、ページタイトル記法）［PageElement、ページ生成時］
    とりあえず /^==/
    セクション記法はページのもの。セクションのものではない。
• ページ→ページ（→セクション0〜1コ）
  Compositeパターン
• 閲覧時展開［Section.toHtml()］／編集時展開［Section.toWikitext()］
  • 権限、錠と鍵
    どちらもページ属性で
    錠はページ、鍵はユーザーが持つ
    権限があるとき見出し＋下位の内容、権限不足時は見出しだけ。
    ページ名はページ内容と編集権限が異なる。接頭辞属性を含むので。
  • 下位の代表見解を展開［Pagename］ ・ページ属性（ページ属性記法）
    属性の自動リンク［Autolink.toHtml()］
  • 情報配置
    錠と鍵（権限）の表示は参照記法を配置して
    ページ参照と関連名フィルタリングをするPageElement、それを配置

• プレビューWiki
  ［Pagename、Wikiを明示指定］
  Previewモード
  指定されたWikiにページが無ければ、デフォルトWikiのページを使う。
  デフォルトWikiにも無ければ、指定されたWikiでページが存在しない処理。
• タイムマシンWiki
  ［Pagename、版の補完方法で］（プレビューとは実装方法が違う）
  Back way to ... モード
  日時指定→版の補完時に版番号に置き換え
  日時指定用のUI: 版の中から選択、あらかじめページ名と見解が指定されていないと
  ページ(Entry)が無ければ、普通にページが存在しないときの処理。

• -------------------------------------

• Notation→ElementでPukiWikiのようにRegex1回にしないのはネストを可能にするため。Notationのネストを内側から探すのも同じNotationをネスト可能にするため。

• ウィキエンジンXのページを自動リンク

そのうちやること †

• 自動リンクルール
  相対パス→絶対パス変換に一手間加えたもの。
• メタページ生成ルール

• 利用者のログイン／ログアウト
• アカウント管理

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

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ページ化。

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

• -------

排他制御 †

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

実装からTips作成 †

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

ASP.NETを使うなら †

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

PageElement系クラス †

• Wikitext
  処理前の文字列状態。
  stringをPageElementとして扱えるようにするクラス。stringからPageElementツリーを作るクラス。 @done
• Document
  1ページに1つだけ。PageElementツリーのルート要素。
• Notation系
  • Nestable系 @done
    中に他のPageElementを含むことができる。 @done
• Autolink
  自動リンク。Plaintextを含む。
• Plain系
  Plaintextを末端とするネスト構造。Plain系のなにか→Plain系のなにか→Plaintext。
  Plaintextは別。PageElements構造の末端。

物理:

	- 領域

		テキストファイルを複数組み合わせて1ページ

		保存しなければならないのは投稿されたままのデータ

		- 表

			- 属性領域

			- 本文

		- 裏

			- 属性領域

		- 書き込みキュー

			- 1トランザクションのなかでキューをページに反映

			- 最新版

				キューを全て反映したページ

			- 現在版

				古いかも？参照用

			- キューの内容は新しいページそのもの

				差分ではなく単体で新しいページになれる。処理の単純化のため。

				反映時は全面書き換え。

──────────────────
属性:

	ページの属性はただNotationを書くだけ。参照時に内容と統合されて1つのelement構造になる。書くところが分かれているだけ。

	- 裏

	- 内部名

	- 凍結

		凍結してるか？はページ/属性。

		編集不可能→編集権限を無視してどんな場合も権限なしと判断。

		凍結解除してから編集、再凍結までを一度に行うことで編集可能に見せることはできる。

		編集ビューは凍結されていても閲覧権限で見られる。

	- 不特定多数には非公開属性=特定者にのみ公開属性

		公開範囲別に複数の属性になる？

	- 隠し属性、ページ名が明示されたときに見える。

	- 古い自動生成ページを自動更新

	- 自動更新間隔。elementが更新間隔を持つ。更新はページごとなので、ページ内で最も短い間隔で自動更新。自動生成ページだけでなく一般化。

		ページの属性

	- 基本がリンクか埋め込みか。という属性。

	- 属性値を書く欄。ほかにページ名の接頭辞も属性値の一部。

─────────────────────
内容:

	- 見出し始まり、無ければ自動で作る

	- ページの分割、統合、入れ替え支援

	- バックリンク

	- ウォッチリスト 

	- Web標準

	- 更新日時一覧には編集対象ページ（編集対象としてパラメーターになったページ）と、実際に更新されたページの両方を載せる。

	- 自分宛のクエリーを読める

	- 自分宛のクエリーはHTML出力で作る

	- 添付ファイルもページ化

	- HTMLテンプレートもページに書く

	- データベースでもある。elementクラス別のデータベースでもある。

	- サイトのアクセスログでもある。ページに記録

	- クリップボードでもある。

	- 多階層ビュー、埋め込みのネスト。html1ページはヘッダーやシステムメッセージ領域など、複数層の埋め込みでできている。

	- 存在しないページはない

	- 更新できるのは自身だけ。遅延書き込みと前バージョン参照

	- DOMアクセス

	内部名と表示名

	項目→ディレクトリ、見解→ディレクトリ、版→ファイル

	内部名を使って

	版、見解はページの応用。

	- 代表

		ワイルドカードを使った一覧から1つ選ぶ仕組み。

	- ワイルドカードで一覧

		ワイルドカードを使った不完全な指定、で、代表を要求しない

		- 項目指定なし、つまり何にもなしのリスト要求

			全ページ一覧

			代表要求するとルート(FrontPage)

		- 見解指定なしのリスト要求

			見解一覧

			投稿できないので、一覧は表示だけ。

			代表要求すると有力見解←投票で

		- 履歴指定なしのリスト要求

			版リスト

			投稿できないので、履歴一覧表示だけ。

			代表要求すると最新版

履歴（版だけ組み合わせ）:

	履歴はモデルに含めない。履歴はワイルドカードを使って検索した一覧。

	- 2履歴間の差分

	- 最新の差分は閲覧ビューでも強調

		クライアント側で

	- 編集履歴（差分）表示

		異なる見解の最新版比較（差分表示）も？

		通常の差分は同項目・同見解・異版間のもの。

下位:

	- 属性の継承

		下位展開と関係ある？

	- 属性の継承、下位ページに

	- 下位展開（閲覧時/編集時）

		下位ページ展開

		- 下位ページの更新は上位の更新日時を変えない。更新日時一覧に上位ページ名も載せる。それで同じ効果。

投票:

	見解に投票

─────────────────────
Archive:

	- 複数のビュー。elementクラスごとに分ける・分けない、どれとどれが同じかなどいろいろ。 @done @project(できること)

	版、履歴: @done @project(物理 / 版、履歴 @done)

	Merge可能かどうかをインターフェイスで。: @project(Merge可能かどうかをインターフェイスで。) @done

		インスタンス生成せずに呼び出すメソッドはインターフェイス化できない。