Up to the present, search fields in Blacklight have been configured
like: Blacklight.config[:search_fields] << ['label', 'solr_request_handler']

Recall that the default Blacklight form only lets you select one search
field at a time, so the search field has the ability to select the solr
request handler too. The expectation with the existing config is that
every search field must correspond to it's own solr request handler.
This is a reasonable way to do things, and often works fine, and should
be supported by Blacklight.

However sometimes you (meaning me) want to re-use the same solr request
handler for more than one search field, but specify some solr parameters
that should be associated with the search field and sent by
Blacklight. Under the up-to-now setup, I found myself
copying-and-pasting request handler definitions in solrconfig.xml, that
would be identical except for, say, the qf and pf fields. This seemed
very un-DRY; I would prefer to use the same request handler, but have
Blacklight know to pass qf and pf params for the new search field.

So this patch changes the search field config to look like this:

Blacklight.config[:search_fields] << {:display_label => "Label", :qt =>
"solr_request_handler", :solr_parameters => {:qf => "something", :pf =>
"something", etc}}

The :solr_parameters key is of course completely optional, you can still
use a one-to-one mapping between BL search fields and solr request
handlers if you like.

To support this kind of config, we need to make some changes in how BL
search forms are submitted. Previously the users choice of search field
in the html select menu simply set a "qt" param in the resulting HTTP
request. But now "qt" (request handler) alone is not sufficient to tell
Blacklight how to deal with the request. So the search form was changed
to send :search_field => some_search_field_key instead of qt. The
search field key can be specified in the search_fields hash (<<
{:display_label => "title", :key => "title" ...), or if unspecified is
computed by taking the display_label and turning it into a nice identifier.

Helper methods that supply the search form were changed to support this.
The search history mechanism had the new "search_fields" http param
added to it's list of things to save with a search. The partials/helper
methods that display a search in human readable format (constraints on
an index page, or the history page) were changed to look up the label
using the new system.

[ For backwards compatibity with possibly existing stored or bookmarked
/index URLs, if no :search_field is in the url, :qt is still used by
code. However, the search constraints won't be labelled with
specificity from such a URL, and the search form select menu will not be
set to the selected search. ]
 

A new module SearchFields was added to DRY the logic for accessing (and
filling in defaults) the new style of search_fields config. It is
currently added to the Blacklight class, like other config, so adds some
Blacklight.* class methods for accessing search field configuration. But
I tried to write the module so it could be used in a future architecture
that might allow individual controllers to define their own search
fields too. Rspec tests for the new SearchFields module were written.


Finally, to accomplish the actual goal, SolrHelper#solr_search_params
was re-written to add solr_parameters from the configured search field
to the solr_search_params used to contact solr. (It does this by looking
at http request params for a :search_field value, and using that key to
look up the search field config, using the SearchField helper module
functions on Blacklight). In the process of tryign to add that, I found
the previous solr_search_params definition to make it kind of confusing
as to what data came from where with what precedence (it was already
taking data from a number of places, including http request, Blacklight
defaults, and method args, with some taking precedence over others).
So I rewrote the method to be more straightforward and clear. I made
sure the rewritten method passed all existing specs and features (there
were some 'gotchas' in there, certain expectations for
solr_search_params output I would not have guessed, but were revealed by
the tests. hooray for tests). I then added rspec coverage for
SolrHelper#solr_search_params, both existing and my new functionality --
there were previously tests that looked at Solr results, but no tests on
the output of solr_search_params itself, but now there are.



So that's what I did, and it's been written thusly. You can look at the
code in a branch of my own github fork:
http://github.com/jrochkind/blacklight/tree/expanded_search_field_config

I will issue a pull request from this fork.