A few fixes for the Marc Expert Search

A few fixes for the Marc Expert Search

Attempting to sort the MARC expert search results in the staff client
caused the staff client to return to the basic search page rather than
sort the results.

As well, sorting was not working at all in the MARC expert search.

To fix the sorting I had to modify two perl files.

metabib.pm had to be changed in a number of ways.

1. The way the sort works currently assumes the user is doing a full
text search.  So, it passes in the values of titlesort and authorsort as
the sort variable in the URL.  However, in the expert search, it is
looking for the values 'title' and 'author'.  This resulted in the title
sort and author sort never being executed and returning the relevance
sort instead. I modified the expert search to use a regex instead of eq.

2. If a record has no value associated with it e.g. no 260 c for
pubdate, no 245 a for title, no 1xx a for author, then the SQL is supposed to
replace those values with either 'AAAA' or 'zzzz' depending on the
order of the sort.  This should cause records without the relevant
sort values to be pushed to the bottom of the sort results.

But, the PgSQL function COALESCE, which is supposed to do the
replacing, does not do anything if no rows are returned for a record's relevant
value.  To work around this, I surrounded the relevant values with the
MAX() function call, which returns null if no row is returned.

Because author sort works on any 1xx value, it sorts those values in
numerical order when there is more than one 1xx in a record.  This
requires the use of an ORDER BY statement, which seems to nullify the
effect of MAX().  So, I had to move the MAX() into a second SELECT
statement in the case of author sort.

3. I added the number_default_sort and string_default_sort to the
metabib code because the current code was hard coding values of '9999'
and 'zzzzzzzz' into the sort.  I believe these hardcoded values are
all that is necessary because of the way ORDER BY works with empty
strings, but I think it is better to be explicit with the sorting values.

Search.pm had to be changed to pass the sort values from the TPAC into
the relevant sort subroutines.  This was done with the addition of an
$arghash variable that checks the cgi parameters for the sort
variable.

Finally, to fix the problem of the staff client returning to the search
page after sorting an expert search, I modified searchbar.tt2.  Currently,
searchbar.tt2 does not have the values from the Expert search entered
into the <form> where the sort functionality is located.  This means, when
a sort option is chosen, the TPAC no longer knows which values were used for
the Expert search.

This is not obvious at first because after choosing to sort, the user
is returned to a page where the URL has the Expert search values in it.
This happens because the sort is submitting a form without a query
value, so the TPAC redirects the user to the referring page, which is
the initial Expert search.

To fix this, I added the Expert search values as hidden variables
into the <form> where the sort functionality is located.  I also removed
the use of the "_adv" hidden variable from the <form> when not in the
advanced search.

Additionally, when paging through the results of the Expert search,
the system will not return more than 100 records.  Going past page 10
causes a no results screen.

This is due to the offset and limit values not being passed into the
argument hash used to create the SQL for the search.  Once the SQL
returns, it returns record ids within the range of the offset and the
limit. So, if the offset is 100 and the limit is 10, the record ids
for search results 100 to 109 are returned.

But, because offset and limit are not being passed into the arghash,
they default to 0 and 100 respectively.  This means the first 100
records are always returned regardless of where in the search page
you are viewing.  These 100 results were then pruned to the relevant 10
results in Biblio.pm.  However, if the offset starts beyond 100 then
no results are returned because the results passed 100 are not
returned by the metabib.pm.

This commit passes the offset and limit as arguments. It also removes
offset and limit as parameters of the search.biblio.marc call.
Because offset and limit are needed in the arghash to limit the number of
records returned, it is better to pass them only via the arghash to
ensure that no more than the necessary number of records are
returned.

Offset and limit could be kept as sub parameters as well, but it would
require modifying metabib.pm to look for those parameters in both the
arghash and the sub parameters, so I think forcing the Expert search
to pass them as argument parameters is the better option.

As well, this commit removes the pruning in Biblio.pm that was based
on the offset and limit because that is handled in metabib.pm now that
the offset and limit are being supplied as arghash parameters.

I have checked the source code and the marc_search function in
Biblio.pm is only called via the Expert search in
WWW/EGCatLoader/Search.pm, so modifying Biblio.pm in this manner will
only affect the Expert search and nothing else.

As well, I corrected some indenation where spaces and tabs were used
on differnet lines in the same file.

Signed-off-by: Liam Whalen <whalen.ld@gmail.com>