RIGHT:[[:t/検索]] [[:t/実装]]
#contents
**機能/一覧にどうスコアが渡るか [#lff08111]
→機能/一覧が独自にスコアを得る。クエリーに書かれた()内がスコアに当たる。
+ページセット作成（ページ名、ディレクトリ指定で）
検索:全ページ（デフォルトのページセット）、一覧:パラメーターを解釈して機能/一覧が作ったページセット
+ページセット作成（パラメーターでフィルタリング）
検索:検索/クエリー、一覧:機能/一覧
+レコードごとにソートキー生成（スコアリング）
検索:検索/クエリー、一覧:機能/一覧
+ソート
検索、一覧、どちらも機能/一覧
ソート以外は統合不可。
→ソートとその後のフォーマットだけ一覧機能の役割にすればいい。
それ以前は検索/クエリーの役割？
検索/クエリーにページセットを受けて、それをフィルタリング（縮小）する機能を。
あとは最初のページセット生成が異なるだけ。
検索では無指定（デフォルトのページセット）、一覧ではパラメーターをページセット化。
→どちらもデフォルトページセットからのフィルタリングその1にできる。
無指定だとページセットは不変、指定があれば指定されたページ名やディレクトリ名に適合するページだけを残すフィルタリング。
→ページセット生成に制限がかかってしまう（フィルタリングルールの指定しかできない）→統一しないほうがいい。
** [#k3af5b4c]
無指定→デフォルト、デフォルトが全ページ、パラメーター指定はページセット生成のためのもの。とすれば？
→ページセット生成パラメーターの解釈はどこが？
→ページセット生成機能が行えばいい。
:ページセット生成機能|
lsのような機能。
閲覧用ではHTML生成、機能に渡されるとき（機能からパラメーターを要求されたとき）はページセットだけを返す。
APIでは挙動が変わる機能。
→パラメーターにlsを渡して、検索/クエリーがフィルタリングとスコアリング、機能/一覧がフォーマット。
**検索（スコアあり）と、表作成（スコアなし）の差をどう埋めるか [#wb4ba56f]
→スコアは検索/クエリーで。それが
スコアなしでは()に当てはまる部分を取り出すことに当たる。()内がスコア。スコアだけど文字列。
その後どちらもスコア順にソート。
**()内は出力されるデータのはず [#qa40f997]
()内はスコアではなく出力されるデータ、検索では適合した辺りのプレビュー、一覧では()内に適合した部分。
スコアは…検索では適合度合いで数値、一覧では()内に適合した部分でこれを文字列としてソート。
絶対値と相対値。数値と文字列。でもソートできる型だから問題ない。
**解決 [#gc06ca3f]
機能/一覧、機能、検索、検索/クエリーに追記。
----
検索の仕組みが変わったので、もういい。
