LP#
1389403 Add normalizer detection to call number browse
When finding the pivot for call number browse, we currently rely on
simple label matching (rather than normalized label matching), since
we do not know at the time of the search which normalizer we should
use.
Rather than blindly using the label, let's select the pivot in two
phases. First, we will do what we do know, getting as close as
possible by label alone. If we find an exact match, we are done (same
as the current code). If we don't find an exact match, we take the
normalizer setting from the closest label match, normalize our input,
then search again.
This method *greatly* improves the overall accuracy of call number
searching whenever the call number being browsed for does not exist,
while causing no harm to accuracy when it does exist (since it will
either match the label or normalize to the same call number anyway).
Eventually, we may want to add interface elements for selecting the
call number type, probably defaulting to the default call number type
for the org unit being searched, but even with that in place, this
"auto-detection" logic should still be valuable.
Signed-off-by: Dan Wells <dbw2@calvin.edu>
Signed-off-by: Kathy Lussier <klussier@masslnc.org>
Signed-off-by: Ben Shum <bshum@biblio.org>