:i/プロトタイピング

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

そのほか †

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をネスト可能にするため。

「C#に依存するコードが増えてきましたが」

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

そのうちやること †

自動リンク †

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

アカウント †

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

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

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

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

排他制御 †

永続化クラスを排他制御不要な方式に。

モデル系クラスでは自分で自身を書き換える。他のクラスを扱うのはPageFactoryくらい。

実装からTips作成 †

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

仕様の分け方 †

フレームワークは空気。ページが本体でユーザーがそれを利用できるようにするのがフレームワークの役目。

UIの内訳
1. 読みUI
ページ/履歴含む。
2. 書きUI
エディターなども。
3. 探しUI
検索の他に関連情報やおすすめの類も。
4. 組み立てUI
管理とWiki構築。テンプレートやデータコンテキストなどページ/要素を使ったプログラミング部分。

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アクセス

名前で3層組み合わせ:

	内部名と表示名
	項目→ディレクトリ、見解→ディレクトリ、版→ファイル
	内部名を使って
	版、見解はページの応用。
	- 代表
		ワイルドカードを使った一覧から1つ選ぶ仕組み。
	- ワイルドカードで一覧
		ワイルドカードを使った不完全な指定、で、代表を要求しない
		- 項目指定なし、つまり何にもなしのリスト要求
			全ページ一覧
			代表要求するとルート(FrontPage)
		- 見解指定なしのリスト要求
			見解一覧
			投稿できないので、一覧は表示だけ。
			代表要求すると有力見解←投票で
		- 履歴指定なしのリスト要求
			版リスト
			投稿できないので、履歴一覧表示だけ。
			代表要求すると最新版
履歴（版だけ組み合わせ）:
	履歴はモデルに含めない。履歴はワイルドカードを使って検索した一覧。
	- 2履歴間の差分
	- 最新の差分は閲覧ビューでも強調
		クライアント側で
	- 編集履歴（差分）表示
		異なる見解の最新版比較（差分表示）も？
		通常の差分は同項目・同見解・異版間のもの。
下位:
	- 属性の継承
		下位展開と関係ある？
	- 属性の継承、下位ページに
	- 下位展開（閲覧時/編集時）
		下位ページ展開
		- 下位ページの更新は上位の更新日時を変えない。更新日時一覧に上位ページ名も載せる。それで同じ効果。
投票:
	見解に投票
─────────────────────
Archive:
	- 複数のビュー。elementクラスごとに分ける・分けない、どれとどれが同じかなどいろいろ。 @done @project(できること)
	版、履歴: @done @project(物理 / 版、履歴 @done)
	Merge可能かどうかをインターフェイスで。: @project(Merge可能かどうかをインターフェイスで。) @done
		インスタンス生成せずに呼び出すメソッドはインターフェイス化できない。