[OPEN-ILS-DEV] searching from remote form

Dan Scott denials at gmail.com
Thu Oct 9 00:20:57 EDT 2008


2008/10/7 Grant Johnson <fgjohnson at upei.ca>:
> Hey,
>
> We just discovered that something like o'grady searched from LibX, or our Webpage, doesn't strip out the "comma" and  I get zero results.
>
> Any idea's other than putting a whole load of javascript on each "remote" form to make the catalogue more usable?
> I expect it functions in a similar fashion with other punctuation.
>
> See this in action by searching for o'grady on the "Find Books and Other Resources" section at http://library.upei.ca

So, the function that appears to be responsible for normalizing input
in the OPAC is searchBarSubmit() in
Open-ILS/web/opac/skin/default/js/search_bar.js with the following
filter lines:

    text = text.replace(/'/g,' ');
    text = text.replace(/\\/g,' ');
    text = text.replace(/^\s*/,'');
    text = text.replace(/\s*$/,'');

Compare that to the filtering in the main search function
multiclass_query in
Open-ILS/src/perlmods/OpenILS/Application/Search/Biblio.pm:

    $query =~ s/\+/ /go;
    $query =~ s/'//go;
    $query =~ s/^\s+//go;

Of primary interest here is that in the JavaScript filtering, a single
quote gets replaced by a space ("O'Grady" becomes "O Grady") - whereas
in the Perl (which is what you would hit with the unaltered versions
of your search forms) a single quote gets replaced by nothing (so
"O'Grady" becomes "OGrady"). Also, backslashes are replaced with
spaces in the JavaScript filter, but allowed to pass through in the
Perl. Thus, different search results from different interfaces.

I think it would be best if, just like the ISSN hyphen filtering, we
pulled the filtering from the client side and made it all happen
server side, so that we can ensure that the results are consistent
from any interface.

-- 
Dan Scott
Laurentian University


More information about the Open-ils-dev mailing list