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