機能/一覧にどうスコアが渡るか Edit

→機能/一覧が独自にスコアを得る。クエリーに書かれた()内がスコアに当たる。

  1. ページセット作成(ページ名、ディレクトリ指定で)
    検索:全ページ(デフォルトのページセット)、一覧:パラメーターを解釈して機能/一覧が作ったページセット
  2. ページセット作成(パラメーターでフィルタリング)
    検索:検索/クエリー、一覧:機能/一覧
  3. レコードごとにソートキー生成(スコアリング)
    検索:検索/クエリー、一覧:機能/一覧
  4. ソート
    検索、一覧、どちらも機能/一覧

ソート以外は統合不可。
→ソートとその後のフォーマットだけ一覧機能の役割にすればいい。
それ以前は検索/クエリーの役割?
検索/クエリーにページセットを受けて、それをフィルタリング(縮小)する機能を。

あとは最初のページセット生成が異なるだけ。
検索では無指定(デフォルトのページセット)、一覧ではパラメーターをページセット化。
→どちらもデフォルトページセットからのフィルタリングその1にできる。
無指定だとページセットは不変、指定があれば指定されたページ名やディレクトリ名に適合するページだけを残すフィルタリング。
ページセット生成に制限がかかってしまう(フィルタリングルールの指定しかできない)→統一しないほうがいい。

Edit

無指定→デフォルト、デフォルトが全ページ、パラメーター指定はページセット生成のためのもの。とすれば?
ページセット生成パラメーターの解釈はどこが?
ページセット生成機能が行えばいい。

ページセット生成機能
lsのような機能。
閲覧用ではHTML生成、機能に渡されるとき(機能からパラメーターを要求されたとき)はページセットだけを返す。
APIでは挙動が変わる機能。

→パラメーターにlsを渡して、検索/クエリーがフィルタリングとスコアリング、機能/一覧がフォーマット。

検索(スコアあり)と、表作成(スコアなし)の差をどう埋めるか Edit

→スコアは検索/クエリーで。それが
スコアなしでは()に当てはまる部分を取り出すことに当たる。()内がスコア。スコアだけど文字列。

その後どちらもスコア順にソート。

()内は出力されるデータのはず Edit

()内はスコアではなく出力されるデータ、検索では適合した辺りのプレビュー、一覧では()内に適合した部分。
スコアは…検索では適合度合いで数値、一覧では()内に適合した部分でこれを文字列としてソート。
絶対値と相対値。数値と文字列。でもソートできるだから問題ない。

解決 Edit

機能/一覧、機能、検索検索/クエリーに追記。


検索の仕組みが変わったので、もういい