yet another talking point strawman

gistfile1.txt

# 1. Get rid of ambiguity in parameters, you pass in user_parameters, from the BL rails app. No 
# need to pass in direct solr parameters, the caller can add them on themselves, eg: 
# i_want_to_force = {:rows => "10000"}
#   solr_search_params(params).merge(i_want_to_force)
#
# 2. Try to make it as easy as possible to add units of logic and remove/replace units of logic
# -- we do that a lot.  This may may be 'too clever', but the analogy is before_filter on 
# controller, remember "before_filter :method_name", this is a similar thing for mapping logic. 

def self.solr_search_params_logic
 @solr_search_params_logic = [:default_solr_parameters, :default_solr_parameters_for_search_field , :etc]
end

def solr_search_params(user_params = params)
  solr_parameters = {}
  self.class.solr_search_params_logic.each { |method_name|  send(method_name, solr_parameters) }
end

def default_solr_parameters(solr_parameters)
    Blacklight.config[:default_solr_params].each_pair do |key, value|
      solr_parameters[key] = case value
                                when Hash then value.dup
                                when Array then value.dup
                                else value
                              end
      end

    # nasty, but the alternative may be worse.
    solr_parameters[:qt] = params[:qt] if params && params[:qt]
 
    solr_parameters
end     

# etc. 

# Now local apps and plugins can add their own logic on to the end of the chain, or at the beginning of the chain, or even replace defualt logic:

CatalogController.solr_search_params_logic << :my_new_method
CatalogController.solr_search_params_logic.delete(:default_solr_parameters) #don't even wnat to do that
 
  
# Or could even provide a DSL if we wanted, similar to before_filter
def self.add_solr_param_logic(method_name) ...

CatalogController.add_solr_param_logic :my_custom_logic