:i/プロトタイピング/Snippet の変更点

• 追加された行はこの色です。
• 削除された行はこの色です。
• :i/プロトタイピング/Snippet へ行く。
• :i/プロトタイピング/Snippet の差分を削除

RIGHT:[[:t/実装]]

CENTER:〔[[追加:プロトタイピング/Snippet]]〕

----

#contents

**HtmlElement [#x16eb493]
HtmlElement
HtmlTextElement

HtmlElements.Tag
HtmlElements.Text
.ToHTML()



**HtmlElementを実装するなら [#r18547b6]

HtmlElements.Tag
HtmlElements.Text

***Tag [#d7add0e2]
-.ElementName
終了タグにも使用。
-.Attr
Dictionary。値がnullなら属性名だけ。
-.innerElements
List。要素はHtmlElements。入れ子構造。長さ0なら子要素無し。空要素タグになる。<br />など。
-HTML
読み専用。

***Text [#l6031d86]
子要素を持たないのでノードにはならない。リーフ。
-.innerText
テキスト。
-HTML
読み専用。

HTML化はメソッドではなく、データを返すだけ。
特別な処理はしない。



**置き換え式Tokenizeでネスト対応パターンをどう書くか [#o19fda44]
- 1文字だけの否定は簡単、2文字 [[…]] の否定は？
 [[(.*?)]]
**自動リンク先 [#p0925ebd]
 自動リンク先
 ─────────────────────
 Archive:
	自動リンク: @done @project(自動リンク @done)
		- 自動リンク規則 @done
		ページ/名前: @done
			（内部名でない名前）表示名について
			- 順不同パス @done
				- 同値判定 @done
				- ディレクトリ指定→サブディレクトリの集合（ページ含まず）
				- ディレクトリ指定→存在するページの集合
	ページ作成: @done @project(ページ作成 @done)
		- 編集ビュー
		ページ/ビューも
		存在しないページの編集ビュー
	- ページ作成 @done @project(できあがり)
	- プレビュー @done @project(できあがり)
	- 既存ページ名は自動リンク @done @project(できあがり)
	- Nestable側のMerge処理 @done


**p05/Usecase [#i5d17b29]
 p05
 Usecase
	Page.Factory
		シングルトン
		new Page.Page()
			Page.LoadInheritedProperties()
			new Page.Element()
				Page.Element.Tokenize()
					Page.Elements.Notation.Generate()
						ページ内容から記法を探す
						Page.Elements.Notation.Pattern
						Page.Elements.Notation.CreateInstance()
							Notations系オブジェクト生成
						new Page.Elements.Wikitext()
							残りはWikitextにしておく
					Page.Elements.Autolink.Generate()
						ページ内容から自動リンク対象を探す
						Page.NameDictionary.GetPageNames()など
						new Page.Elements.Autolink()
							CreateInstance()では？Autolinkはサブクラスのない唯一のクラスなのでリフレクションにしていない
						new Page.Elements.Wikitext()
							残りはWikitextにしておく
					Page.Elements.Plain.Generate()
						ページ内容のその他の部分をPlains系オブジェクトに詰め込む
						Page.Elements.Plain.CreateInstance()
							Plains系オブジェクト生成
			Page.Element.InAction()
				Notations系、Plains系、Autolink、Wikitextなどがそれぞれの特殊効果を発揮
			Page.Page.ToHtml() | Page.Page.ToWikitext()
				Page.Html生成
		つまりページ生成が終わった時点で記法解析もデータ変換も検索もページ編集も終わっている
		検索やページ編集は記法になっている。Elements.Notations系のオブジェクト。
	Page.Html
		参照するだけ


**自動リンク2 [#q2c6211c]
優先順: @done
	- 1.開始位置が先の @done
	- 2.長い単語 @done
- リンクルールにはリンク先候補も合わせて渡す
	リンク先候補は通常全ページ
	ページリスト記法などで渡せるように
- 作ったページの位置によって同じページ名の自動リンク先が変わる
省処理化:
	- リンク対象（明示的リンクのリンク記法なし）と、リンク先候補のフルパスセットを受けて、明示的リンク処理できれば自動リンクにも使える
	- bi-gramを取り出せない短さの単語（ページ名単語）は｜でつないで正規表現化、Match、マーク
		1つのbi-gramあたりの関連idx（対象テキスト上の位置）が異常に多い場合も、こうしたほうが早いかも
		bi-gramマークのあと、まとめて行なう
	- マークの連続（重複でなく）もあり得るので、リンクルールでは複数のリンクを返せるように
─────────────────────
曖昧さは文字の同一視で実現できるものだけにする:
	明示的、自動リンク両方で。
	ページ名と対象WikiText内の同一視する文字を統一、以降は曖昧さについて考えない。
	- 同一視後の同じページ名が複数のページを指すかも知れない。同一視後の文字列から同一視前が得られるようにしないと。厳密に調べられるように。
	文字の同一視:
		ページ名側の同一視は予め済ませておける。
		- 「ー」の有無、全角半角、大文字小文字、ひらがなカタカナ
		- 同一視すると同じページ名が複数現れる
			リンク先が複数見つかるということ。それらの中から1つ選べばリンク先が決まる。選択ルールは適当に。
────────────────────
問題:
	- リンクできなくてもDanglingLinkにはする @todo
	- 検索ではリンクテキストもリンク先ページ名も両方対象に
	- テキストとリンク先が異なる
		問題なし。
		語順が異なるくらい、相対リンクのときはリンク先のほうが長いフルパスになる。
────────────────────
Archive:
	- 区切りの有無に関わらず、文字（またはbi-gram）→ページリスト内単語のハッシュインデックス使用 @done @project(省処理化)
		- 同じ単語の位置連続がその単語長だけ続いている部分に単語が存在することになる @done
	- 対象テキスト側bi-gramと、ページ名リスト側bi-gramの共通部分取得、必要なデータはそれだけ @done @project(省処理化)
	- bi-gram→単語と対象テキスト上の位置。これを使って文字列の同値判定。位置・長さ付きのindexOf() @done @project(省処理化)
	- マーク付け。マークが連続するだけまとめてリンクルールへ @done @project(省処理化)
	暗黙的リンク、自動リンク: @done @project(暗黙的リンク、自動リンク @done)
		自動リンクの発見方法。暗黙的。
		- リスト内の順序は優先順位 @done
			リンク範囲を探す段階では優先順位など無意味。ページ名内単語を探してマークするだけなので。
			→リンクルールに優先順位を伝えればいい。 @ans
	- 全ページ名探索は必要 @done @project(省処理化)
		- ハッシュインデックスは1対多の探索に使える（テキストと全ページ名単語に） @done
	- テキスト側bi-gram＝ページ側bi-gram→ページリスト内単語と単語内で現れる位置 @done @project(省処理化)
	- これをテキストから得たbi-gramマップ上に配置 @done @project(省処理化)
	- 単語が区切り文字（複数？）だけを挟んで1つ以上並んでいる部分をまとめて1つの自動リンク対象に @done @project(省処理化)
	- 自動リンク対象テキストと、リンク候補（ページ名セット）をリンクルールに渡す @done @project(省処理化)
	- リンク先候補のデフォルトは全てのページ、指定も可能 @done @project(省処理化)
	- 詳しいリンク判定は別に行なうので、まず（ページ側）リンク対象の範囲を調べる。 @done @project(暗黙的リンク、自動リンク)
		ページ名集合に存在する単語と区切り文字の連続する範囲の検出。
	自動リンクは順不同対応するか？: @done @project(暗黙的リンク、自動リンク / 自動リンクは順不同対応するか？ @done)
		- しないと分かりにくい
		- ページ名集合に存在する単語と区切り文字の連続なら、順不同で自動リンク化
	区切り文字あり/なしを分けて考えると: @done @project(暗黙的リンク、自動リンク / 区切り文字あり/なしを分けて考えると @done)
		- 区切りなし→全ページ名探索。いずれの方法でも。
			ページ名探索を省処理化する
	リンクルールにはどんなデータを渡すのか？: @done @project(暗黙的リンク、自動リンク / リンクルールにはどんなデータを渡すのか？ @done)
		明示的、暗黙的（自動リンク）両方で。
		- リンク化対象テキストと、リンク候補のページ名リスト @done
			リスト内の順序は優先順位
		- 戻り値はElementリスト。つまりNotationsの場合と同じ。 @done
		- 戻り値が明示的リンクか暗黙的リンクかはどう分けるか @done
			- 戻り値はリンク範囲と、リンク先ページのフルパス（つまり共通） @done
				複数返せない
				範囲を指定しているので複数返せなくてもいい
	- 戻り値ではリンク化後のテキストを返すか、Matchオブジェクト相当のデータを返す。 @done @project(暗黙的リンク、自動リンク / リンクルールにはどんなデータを渡すのか？)
		弱いリンク記法を施したテキスト。ElementStructだと後がやりにくい。 @done
		つまりリンクルール＋リンク処理 @done
		このあとTokenize？処理重複 @done
		- リンクしたページ名セットもあれば有用
			同じパラメーターの別処理でもいい。
		渡したテキストは必ず全体がリンクになっている。
			必ず全体なら返さなくてもいいかも
	- 順不同なので、ツリー状インデックスは使えない @done @project(暗黙的リンク、自動リンク / 自動リンクは順不同対応するか？)
	- 区切りあり→区切りなしと同様、ただしあとに続くページ名を目印にして省処理化できる @done @project(暗黙的リンク、自動リンク / 区切り文字あり/なしを分けて考えると)
		対象テキスト全体から探索する必要はないし、全てのページ名単語を探す必要もない。
		- 省処理化を別に考えると、区切りなしと同様
	テキスト全体がリンク化するとは限らない。 @done @project(暗黙的リンク、自動リンク / リンクルールにはどんなデータを渡すのか？)
	- まとめないほうがいい？ @done @project(暗黙的リンク、自動リンク / リンクルールにはどんなデータを渡すのか？)
	ページ名必須とする: @done @project(暗黙的リンク、自動リンク / ページ名必須とする @done)
		- リンク対象テキストにはページ名として作った単語が必須 @done
			処理簡略化と、使う時の分かりやすさのため @done
			使う時の分かりやすさのため @done
		- リンク対象テキストは（ディレクトリ名複数＋区切り文字複数＋ページ名1つ）を複数含む @done
			- つまり、インデックスを使わずにリンク対象全体をリンクルールに渡しても結果は同じ @done
		- ページ名必須なら、先にページ名だけを探したほうが早くなる @done
			- ページ名の左に区切り文字とページ名単語が続く限り1つのリンクルール引数 @done
	- 区切りなしの探索に @done @project(省処理化)
	- 区切りあり探索ではページリスト内単語→フルパスリストのハッシュインデックス使用 @done @project(省処理化)
	区切り文字で切った時、前後にそれ以外の文字列が残っているが: @done @project(区切り文字で切った時、前後にそれ以外の文字列が残っているが @done)
		... tag/tag2/page ... -> "... tag", "/", "tag2", "/", "page ..." -> "... " と " ..." が余計。
		- 明示的リンク処理を部分一致にすればいい
			区切り文字を含まない自動リンクにも対応できる。
			- 区切り文字を含まないリンク対象部分があるので、1つの区切り区間に複数のリンクが作られる
				- 区切り文字で切るのは区切りを含むリンク対象を探す時だけにする
					- 1つの区切り区間にページ名は最大でも2つまでということになる
					- 部分一致、でも先頭か末尾のいずれかを含む一致だけになる。どちらも含まない一致はあり得ない
				- 対象ページを1つのテキストにしたままで区切り文字を含まない自動リンク処理を
					- 全ページ名を探索する必要はある
		- あるいは、ページリスト内の全単語を探索して正確にリンク対象を検出すればいあ
			正確に検出できればあとは明示的リンク処理と全く同じ
	- 調査対象ページを区切り文字で切る。その単語単位で処理。 @done @project(暗黙的リンク、自動リンク)
		複数のページ名が含まれるので、ソートできない→順不同に対応できないので、やらない
	- リンク対象になりそうな語（ページ名集合に存在する語）を検索、対象ページ側の語にマーク付ける。 @done @project(暗黙的リンク、自動リンク)
	- マークの連続する範囲を抽出、1つのリンク記法として扱う @done @project(暗黙的リンク、自動リンク)
	- 渡したテキスト全体を一つのリンクに？ @done @project(リンクルールにはどんなデータを渡すのか？)
	- リンク範囲が重複しそうなら戻り値も重複、呼び出した側で一つを採用？ @done @project(リンクルールにはどんなデータを渡すのか？)
	ディレクトリ名は順不同なので、正規表現は使えない。 @done @project(暗黙的リンク、自動リンク)
	リンクに不要な語が含まれるので、ソートしても正規表現は使えない。 @done @project(暗黙的リンク、自動リンク)
	- ページ名（フルパスの最後の語）は必須なので、まずこれを検索 @done @project(暗黙的リンク、自動リンク)
	- 省処理化でツリー状インデックス作成 @done @project(区切り文字あり/なしを分けて考えると)
		- ページ名リスト全体を表す
		- ノードはページリスト内単語
			- ルートはルートディレクトリ名（Wikiサイト名）、リーフはページ名？  @todo @done
				- ページ名から始まらないと使えない。フルパスでないディレクトリ＋ページ名でも自動リンク化するので。
	- 部分一致にした上で、一度に複数のリンクを検出するようにしないと。 @done @project(区切り文字で切った時、前後にそれ以外の文字列が残っているが)
		- それ自体が全ページ名を探す処理では？ @done
	複数処理する？: @done @project(リンクルールにはどんなデータを渡すのか？ / 複数処理する？ @done)
		- できる。していい。リンク化は0回以上になる @done
		- 分ける意味がない @done


**Tokenze15 [#gc6ddbd2]
Elementsループ（大きいidx）
	毎回大きいidxが進むとは限らない。小さいidxもクリアされるとは限らない。
	- 1.Begin+End （継続あり）
		Match Begin
		Match End
			マッチ位置はBeginの直後しか認めない。位置違いはマッチせず。
		パラメーターElem.Add
		小さいidx++
	- 2.Content 前回から継続しているなら
		Match Content
			マッチ位置は先頭しか認めない。位置が違えばマッチしていないとみなす。
		パラメーターElem.Add
		小さいidx++
	- ループ制御
		継続判定
			使うのは最後のMatch。BeginかContentかは問わない。
			Match ∧ Match範囲が末尾の文字を含む ならスキャン済みで次は継続。小さいidxすすめて次。
			Match ∧ …含まないならまだ未処理部分が残っている。大きいidxそのままで（小さいidxだけすすめて）次。継続フラグOFF
			Match していなければスキャン済み。小さいidxすすめて（大きいidxもあとで++することになる）して次。継続フラグはOFF
			結局、継続判定して小さいidxを進めるだけ。
		小さいidxが末尾⇒大きいidx++、小さいidxクリア
		生成
			Tokenize再帰
				Elementリストを渡すオーバーロードを使う。
					どうせ@Elementをループしなければならないので最初からリストを渡せていい。
				探し済みの（優先度の高い）Notationはもういい。すべて変換済のはず。再帰時にターゲットから外す。
				戻り値はElementリスト。そのままChildrenにできるように。WikiTextオブジェクトを含まない
			Elements_.Add←Element生成←パラメーター
				継続分のElementはそのまま渡す。変換不要。ただし最後の1要素みたいな途中までのマッチなら分割しないと。


**Tokenize [#n339836a]

- マッチ部分をコンストラクターに渡す
- WikitextでTokenize @done
Notations系2系統、Variables系、Plains系に渡った時点ではTokenize不要なので。 @done
────────────────────
Wikitext.Tokenize():
Notations系ループ
	Elementsループ（Wikitextのみ対象）
		大idxはElement、小idxは1Element内文字列の
		- 1.Notations系がBegin+End型 （継続あり）なら
			スタックは（大idxと小idx）のスタック
			Begin位置とEnd位置を同時に登場順に処理
			Begin位置はスタックに追加、End位置は見つかるたびにスタック.pop()、対応付ける
				スタックアンダーフローするなら、そのEndは無視
				このスタックは分割してもずれない。すべて分割位置より左なので。
			Begin Endの対応付けができたら
				分割×2、間をParamElem.AddRange
				生成
				次はEndが見つかった次の文字から
			これをEndが見つからなくなるまで
		- 2.Notations系がContent型なら
			Match Content
			マッチしたら
				分割×2、なんらかの方法でマッチ部分をパラメーター化
				生成
			これをマッチしなくなるまで
		- 生成
			再びTokenize→コンストラクターにChildrenになるよう渡す
			Elementリストを渡すオーバーロードを使う。
				どうせ@Elementをループしなければならないので最初からリストを渡せていい。
			探し済みの（優先度の高い）Notationはもういい。すべて変換済のはず。再帰時にターゲットから外す。
			戻り値はElementリスト。そのままChildrenにできるように。WikiTextオブジェクトを含まないこと。
			Elements_.Add 生成したobjを
		- ループ制御
			生成していない場合、Elements_.Add 要素のコピー
			大きいidx++
────────────────────
プラグイン開発の説明を分かりやすく:
	- 前後型、中型に分ける。
	- 前後…間にあるものはElementでもどんな文字でも取り込み、Childrenにする。継続する。
		継続判定は簡単になる。
		「取り込み用」「内容自由だったり他の記法も飲み込む記法」という説明。
	- 中…継続しない。他のElementで切られるとマッチしない。Childrenは取得できるが自由欄とするのは非推奨。（継続しないので）。選択肢ならいい。
		例えば &tip;、---- のように他のElement（PlainTextなども）を持たないもの。
		「内容を持たない記法」「選択式パラメーターを持つ記法」と説明。
		Dateはこっち。制限付き（フォーマットありの）自由欄。
- 継続中の（間の）ElementとMatchが混ざるようなことはない→問題なし
分割したらMatch.Indexがずれるのでは:
	- Matchを捨てる
	- RegExp部分の継続はないので、キャプチャー回数はたかだか1回。Groupは任意個。つまりMatchではなくGroup数だけ文字列を用意すればいい。
複数パラメーターを受けるNotationは:
	- Begin-End型を使って、コンストラクターで中間をSplit()
────────────────────
Archive:
	- Notations系コンストラクターのwikitext→innerElements @done
	毎回大きいidxが進むとは限らない。小さいidxもクリアされるとは限らない。 @done
	（Beginがないなら）Match Begin @done
		マッチしたら @done
			Begin保存、分割予定位置保存 @done
			小さいidx++ @done
		マッチしないなら @done
			小さいidxを末尾へ @done
	（Beginがあるなら）Match End @done
		マッチ位置は直近のBegin以降しか認めない。位置違いはマッチせず。 @done
		マッチしたら @done
			End保存、分割予定位置保存 @done
		マッチしないなら @done
			小さいidxを末尾へ @done
	保存していたBegin Endをクリア @done
	idxはそのまま（分割後の最初の要素のまま）で、次のNotations系へ。分割されたのでこのNotationはもうマッチしないはず。 @done
	idxはそのまま（分割後の最初の要素のまま）で、次のNotations系へ。分割されたのでこのNotationはもうマッチしないはず。 @done
	小さいidx++ @done
	マッチしないなら @done
		小さいidxを末尾へ @done
	継続中のその他Elementはそのまま渡す。変換不要。ただし最後の1要素みたいな途中までのマッチなら分割しないと。 @done
	小さいidxが末尾⇒大きいidx++、小さいidxクリア @done
	Elements←Elements_ @done
	継続判定 @done
		使うのは最後のMatch。BeginかContentかは問わない。
		Match ∧ Match範囲が末尾の文字を含む ならスキャン済みで次は継続。小さいidxすすめて次。
		Match ∧ …含まないならまだ未処理部分が残っている。大きいidxそのままで（小さいidxだけすすめて）次。継続フラグOFF
		Match していなければスキャン済み。小さいidxすすめて（大きいidxもあとで++することになる）して次。継続フラグはOFF
		結局、継続判定して小さいidxを進めるだけ。
	継続とMatchの相性が悪い: @done @project(継続とMatchの相性が悪い @done)
		- 継続中（前後型）の全ElementはElementリストとして渡す
			前後型ではMatchがないので競合しない。
		- Match（中型）もキャプチャーがあるので渡さなければならない。複数
			中型では継続がないので競合しない。
		- 前後型のMatchも渡す
			前後型のMatchは一対だけ。継続と競合しない。
	- RegExpを分けること、どう分けるかが分かりにくい @done @project(プラグイン開発の説明を分かりやすく)
	- Match →分割 →新しいMatch？ @done @project(分割したらMatch.Indexがずれる)
	- Matchを作り直せれば簡単。 @done @project(分割したらMatch.Indexがずれる)
	- Matchでないものを生成に使う？ @done @project(分割したらMatch.Indexがずれる)
		プラグイン開発の説明が難しくなるのでは
	- 後ろから検索すればずれない。けど前から検索のインデックスに変換しないといけないので結局新しいMatchと同じこと。 @done @project(分割したらMatch.Indexがずれる)
	- 継続時のMatchが分断されているので、まとめる？→Match以外にして？→Begin-EndのときもMatch以外でいいのでは @done @project(分割したらMatch.Indexがずれる)
		継続時のMatchはない。 @done
	- 分断したままで、ならMatch1つにRegExp内にあるだけのGroup、その中に複数のCapture、という構成で。 @done @project(分割したらMatch.Indexがずれる)
		Matchを作れないなら模したもので。 @done


**ol [#x6bc2d70]
 ol->
	li->a
	li->
		b @todo
		ol->
			li->b1
			li->b2
	li->c
 ────────────────────
 +a
 +b @todo
 ++b1
 ++b2
 +c
 ────────────────────
 ol->li->a
 ol->li->b @todo
 ol->li->ol->li->b1
 ol->li->ol->li->b2
 ol->li->c
 ────────────────────
 ol->
	li->a
	li->b @todo
	li->ol->li->b1
	li->ol->li->b2
	li->c
 ────────────────────
 ol->
	li->a
	li->b @todo
	li->ol->
			li->b1
			li->b2
	li->c
 ────────────────────
 ol->
	li->a
	li->
		b @todo
		ol->
			li->b1
			li->b2
	li->c
 ────────────────────
 <ol>
	<li>a</li>
	<li>b @todo
		<ol>
			<li>b1</li>
			<li>b2</li>
		</ol>
	</li>
	<li>c</li>
 </ol>
 ────────────────────
 1. a
 2. b @todo
	ⅰ. b1
	ⅱ. b2
 3. c


 <ol>
	<li>a</li>
	<li>b @todo</li>
	<ol>
		<li>b1</li>
		<li>b2</li>
	</ol>
	<li>c</li>
 </ol>


**ToDo0 [#r1d7456a]
Archive:
	- テキスト整形のルールの冒頭に「ネストできるようにしたら こうなりました。」 @done
	インデントでサブページを作るか？ @done
	全検索キーの適合率が０のときだけフィルタリング。ページセットからはずす。 @done
	%%検索スコアはソートキー。フィルタリングで算出。フィルタリング処理だけのコードで。%% @done
	%%検索スコアは偏差値。%% @done
	%%クエリー側Elementごとにページ1つあたりの最高適合率を得て、他ページ同ソートキーの最高適合率と比べて偏差値算出、その偏差値を1ページ分合計、そのページのスコアにする。%% @done
	%%　　　　キーA　キーB　キーC　合計%% @done
	%%ページ2　　26　　68　　　12　106%% @done
	%%ページ1　　31　　23　　　5　　59%% @done
	%%でも数値化できないソートキーは？%% @done
	%%クエリーには検索キーワード…フィルタリングで使用、検索ソートキー…フォーマットで使用の2種類のデータが含まれる。書式は使用するフィルタリング・フォーマットによる。%% @done
	%%グローバルな領域に一時的な共有領域（Dictionary）を。クラス→値名（文字列）→値（Obj）。%% @done
	%%レスポンスまでデータ維持。%% @done
	%%ここにフォーマット向けのサマリーを置く。読む方のクラス名→ページ内部名→サマリー%% @done
	%%フィルタリングで書き込み、フォーマットで読み込み。%% @done
	%%読み書きの両方で同じキー名を使う必要がある。%% @done
	%%フィルタリングの内部はデータコンテキスト。%% @done
	%%フォーマットの内部はデータコンテキスト。%% @done
	%%フィルタリングもフォーマットもネスト可能。%% @done
	%%フォーマットはWikitextに変数を埋め込んだもの。%% @done
	%%テンプレートとその展開コードは基底クラスで定義するが、基本はフォーマットの子孫でそれぞれ展開方法を定義。%% @done


**ToDo0 [#v5c34325]
Archive:
	- テキスト整形のルールの冒頭に「ネストできるようにしたら こうなりました。」 @done
	インデントでサブページを作るか？ @done
	全検索キーの適合率が０のときだけフィルタリング。ページセットからはずす。 @done
	%%検索スコアはソートキー。フィルタリングで算出。フィルタリング処理だけのコードで。%% @done
	%%検索スコアは偏差値。%% @done
	%%クエリー側Elementごとにページ1つあたりの最高適合率を得て、他ページ同ソートキーの最高適合率と比べて偏差値算出、その偏差値を1ページ分合計、そのページのスコアにする。%% @done
	%%　　　　キーA　キーB　キーC　合計%% @done
	%%ページ2　　26　　68　　　12　106%% @done
	%%ページ1　　31　　23　　　5　　59%% @done
	%%でも数値化できないソートキーは？%% @done
	%%クエリーには検索キーワード…フィルタリングで使用、検索ソートキー…フォーマットで使用の2種類のデータが含まれる。書式は使用するフィルタリング・フォーマットによる。%% @done
	%%グローバルな領域に一時的な共有領域（Dictionary）を。クラス→値名（文字列）→値（Obj）。%% @done
	%%レスポンスまでデータ維持。%% @done
	%%ここにフォーマット向けのサマリーを置く。読む方のクラス名→ページ内部名→サマリー%% @done
	%%フィルタリングで書き込み、フォーマットで読み込み。%% @done
	%%読み書きの両方で同じキー名を使う必要がある。%% @done
	%%フィルタリングの内部はデータコンテキスト。%% @done
	%%フォーマットの内部はデータコンテキスト。%% @done
	%%フィルタリングもフォーマットもネスト可能。%% @done
	%%フォーマットはWikitextに変数を埋め込んだもの。%% @done
	%%テンプレートとその展開コードは基底クラスで定義するが、基本はフォーマットの子孫でそれぞれ展開方法を定義。%% @done


**複数条件Regex方式 [#i0cdf932]
- ネスト可能にするなら同時待ちは無駄。1つずつループのほうが効率的。 @ans
────────────────────
Archive:
	ネストの外側: @done @project(ネストの外側 @done)
		- 外側が残る
		- 内側から
		- 内側のあと、外側がつながる
			- ループすれば外側が見つかる
			- マッチが無くなるまでループ
			- つながった状態とは @todo
	ネストの内側: @done @project(ネストの内側 @done)
		- 再帰
	ネストしている複数のNotationが一度に見つかるかも: @todo @done @project(ネストしている複数のNotationが一度に見つかるかも @todo @done)
		- ...[[...{...}...]]...
			- [[...]]が優先されるなら{...}は何を処理するのか？再帰呼び出しで処理済みの部分をMatchesループで重複処理？


**自動リンクの実装 [#y121f256]
RIGHT:[[:t/自動リンク]] [[:t/実装]]

古い資料。

─────────────────────
Archive:
	自動リンクは特別か: @done @project(自動リンクは特別か @done)
		- パターンが決まっていないので、Notations系とは違う
		- 変換が起きてNotationオブジェクトができるのでPlains系でもない
		- Notationsより低優先度 @_
			- 未解析部分を対象にするということ。
	やること: @done @project(やること @done)
		- 第三の系統を作る
			- VariableNotations
		- 順不同パスをどう見つけるか
			- 順序はソートして統一
	クラス: @done @project(クラス @done)
		- Factoryメソッドを持っている
			Tokenize
	- リンク記法生成にするならNotationの前に処理 @done @project(自動リンクは特別か)
		- このあとにまたリンク記法を変換すればいい。でも明示的ではなく暗黙的リンク記法。 @done
			+ 明示的リンク記法などNotations系
			+ Plainsの一部を自動リンク記法化
			+ 自動リンク記法を処理
	- それにElement1つぶんのWikiTextを与えると、ページ名を<>に置き換えたWikiTextと、生成したElementセットを返す→Notationsぶんと統合 @done @project(クラス)
		<>を使うルールは広げないほうがいい。
	- FactoryはNotationsやPlainsにも実装予定。Elements系を1回ずつ呼べばネスト解析。 @done @project(クラス)
	- 出力がHTMLタグ付きになるので、Plains系でもない @done @project(自動リンクは特別か)
	- 置き換えは共通コード。その後個別のコンストラクターを呼ぶので、クラス情報も渡す。共通部分でクロージャ生成、Replaceとそこから呼ぶDelegateを生成、Delegateからは引数渡し（でクロージャが受けた）のクラス情報を使用。 @done @project(クラス)
	- インデックス参照、必要なパターンを生成 @done @project(やること)
	- パターン生成時に対象ページや親Elementを使える @done @project(やること)
		対象ページは既に使えるはず。親Elementは渡す。
	可変パターンのNotationを作るか: @done @project(可変パターンのNotationを作るか @done)
		- 3つめの系統
		- フレームワークの拡張
	- すべてのパターンを作る 全順列 @done @project(やること)
	やっぱり: @done @project(やっぱり @done)
		- Notation系の1つ、パターン生成時にページ参照、bi-gramインデックスを引いて必要なパターンだけ生成、あとはNotation系と全く同じ @done
		ページ片は親Elementが持っている。パターン生成時に参照できるか？ @done
	状況により生成されるので。ページ作成で既存の全ページが影響しないように。 @done @project(結局)
		- リンクElement生成（弱いリンク）
		リンク記法（強いリンク）とは別
	- 処理順はNotationsの後に、Plainsか自動リンク @done @project(自動リンクは特別か)
	Notationじゃなくていい: @done @project(Notationじゃなくていい @done)
		- リンク記法生成。プラグインではない @done
		- 文字列置き換え（追加）だけ @done
		- Tokenizeの先頭で呼び出し PageElementの葉1つが担当するWikiTextを処理 @done
	二重置き換えをどう防ぐか: @done @project(二重置き換えをどう防ぐか @done)
		ヒットする文字列だけならヒットさせない？→適切でない場合がある @done
		有効なNotationクラス指定で→自動リンクはクラスにしていない @done


**自動リンクの問題点 [#j47ed087]
────────────────────
Archive:
	- テキスト側で単語が並んでいる必要あり @done
		- 逆にテキスト側にページ名単語に無い単語が含まれていれば、そこで切って別々にリンク確定 @ans @done
		- 単語が区切り文字（1つ～複数可？）だけを挟んで並んでいるなら1つのリンク対象としてリンクルールに渡す @ans @done
	- リンクルールにはリンク先候補も合わせて渡す @done
		リンク先候補は通常全ページ
		ページリスト記法などで渡せるように
		ページセット記法などで渡せるように
	- 中抜けテキストでも自動リンクになるならリンク1つの範囲が決められない @done
		ソートする前。テキスト側のどの部分をソートしてリンクルールに渡すか
	- まずやることはテキスト内にあるページ名単語の分布表を作ること @done
		- 正規表現を前後に分けるか
			- 前中、中後 @done
				- それぞれ連結
				- 前中のあとに中後でなければならない @done
				- 2つある「中」は違っていていい。中を1文字以上となると、片方当たらなくてもいいようにしないと。 @done
				- 1要素に両方当たるケースはどうする？  @done
			- 複数パターン同時待ちのときカッコの対応が分かるように @done
			- 文字列化できて、そのときは<>で代替表現。シリアライズ。デパース？アンパース？
			- 文字列から戻すこともできる。デシリアライズ。パース。
	解析時、テキストを分けつつ分けないには？: @done @project(解析時、テキストを分けつつ分けないには？ @done)


**TokenizeをPageElementへ？ [#ebadb68d]
PageElement.Tokenize() → PageElement.Tokenize()
PageElement.Tokenize() → PageElements.Plain.Tokenize()

PageElement.Tokenize()
	List<PageElement> tokens = PageElement.Tokenize(this.Document, HttpUtility.HtmlEncode(this.Wikitext), allowClasses, ignoreClasses);

PageElements.Plain.Tokenize()
	List<PageElement> tokens = PageElement.Tokenize(this.Document, HttpUtility.HtmlEncode(this.Wikitext), allowClasses, ignoreClasses);

呼び出し順はPageElement.Tokenize()→Plain.Tokenize()の順、なのでこの順で呼び出すPageElement.Tokenize()を用意、外部からはPageElementのを呼ぶ。

**コンテキスト [#u624a44f]
 コンテキスト:
 データコンテキストとHTMLコンテキスト。
 Elementではコンテキスト別にメソッドを用意。どれが呼ばれるかは親要素による。
 - HTMLコンテキストでの出力にWikitextは含めない。
 ただしWikitextを利用してHTMLを統一するべき。 @done
 - 各Elementの内部でWikitext生成→それを変換してHTML化する。

**Snippet/ [#cc5120aa]
#ls