Add field configuration for :include_in_request. If true, the field will...

[cbeer]

... be explicitly added to the request made to solr. Otherwise, Blacklight assumes the appropriate configuration is made in the solr config. Attempts were made to keep this change backwards compatible with existing practice.

The configuration looks like:

config.add_facet_field 'yes_facet', include_in_request: true # will be added as a `facet.field`
config.add_facet_field 'no_facet', include_in_request: false # will not be added as a `facet.field`
config.add_facet_field 'some_facet'

config. add_facet_fields_to_solr_request! # add all facet fields to solr
config. add_facet_fields_to_solr_request! 'some_facet' # add the 'some_facet' field to the solr request

Same goes for add_index_field/add_show_field and add_field_configuration_to_solr_request.

[eranhirs]

I want to discuss here what you wrote me in #781 as an usage example:

before_filter only: :index do
  blacklight_config.add_facet_fields_to_solr_request!
end

before_filter only: :facet do
  blacklight_config.add_facet_fields_to_solr_request! params[:id]
end

The problem in this example is that it's not part of the configuration anymore, it's more like a runtime decision. Sounds a bit weird to change the configuration in runtime.

What do you say?

[eranhirs]

@cbeer if you're OK with using the before_filter example you wrote me, I'll be happy to rewrite #781 without using user_params. I can do it quite easily.
@jrochkind what do you think?

[jrochkind]

I'm still having trouble keeping up.

If you need special local behavior for something not ordinarily included in Blacklight, and you can do it with a before_filter, that seems great.

If you guys are suggesting including default Blacklight CatalogController setup such that it uses a before_filter, that seems undesirable to me.

Including a method off of blacklight_config meant to be called from a before_filter seems confusing to me. If I understand right, it's introducing something that works in parallel with the "solr search logic" stuff, but is different from it, so there are now two mechanisms that both work on the solr parameters, the solr_search_logic stuff, and a before_filter that calls something off blacklight_config. That seems awfully confusing.

Again, while I see the undesirability of the current architecture you are talking about -- there are unfortunately many undesirable parts of the BL architecture, it's important the cure not be worse than the disease as far as maintainability, and complexity of code and cognitive load in understanding it is a big part of maintainability. This part of BL may be too hard to understand now, it's important not to make it worse.

[cbeer]

I'm not suggesting the default include this behavior, just that it's an option if @eranhirs actually wants/needs that behavior.

We've supported run-time configuration of blacklight for some time now. This patch doesn't introduce any new methods, and just refines an existing one.

(For the purposes of this patch, the before_filter proposal is irrelevant anyway. Allowing the developer more control which parameters Blacklight should send is a helpful step to getting more solr configuration back into the request handler without needing to fully commit at the outset.)

[jrochkind]

yes, agree that for local behavior, before_filters are appropriate. Not quite sure what we're talking about, but I don't need to be.

[eranhirs]

@cbeer I agree, this is a great PR irrelevant whether I will use it in before_filter or not locally.

[jcoyne]

can the inner block be a method? It could be resused on line 351 too.

[cbeer]

Sure. Updated.

[jcoyne]

I like it.

[jrochkind]

Why not leave the old add_facet_fields_to_solr_request there ALSO, as a shortcut for specifying : include_in_request => true for every single facet you add? I want them all included, it was convenient to be able to say to include them all.

I don't really understand the use case for wanting to include some of them but not all of them; I trust there is one, but the use case for wanting to include all of them remains and I suspect is common?

[cbeer]

@jrochkind that's exactly what this commit does.

EDIT:
Oh, I get your confusion now. There's an internal add_facet_fields_to_solr_request variable that records whether the "public" API method add_facet_fields_to_solr_request! was called. I've marked the internal method add_facet_fields_to_solr_request as deprecated because, presumably, it is unnecessary.

I originally had some code that iterated over e.g. all the facet fields when it was called to set include_in_request: true, but we have some code still that expects to be able to call add_facet_fields_to_solr_request! in any order (e.g. add facet fields and then call it, or call it and then add facet fields), which made things confusing. I took it out in the commit we merged, until we decide to drop that 'feature' or have a way of providing global defaults. In any case, it's something to revisit when we're getting ready to break API compatibility in the future, but not an immediate concern.

[jcoyne]

@jrochkind There is a method add_facet_fields_to_solr_request! that adds all of them.

[jrochkind]

Okay, cool.

Why not leave the backwards compatible way to do this though, instead of requiring code to be changed to do the same thing using a new method?

[cbeer]

@jrochkind what's backwards incompatible about it? I went to great pains to keep it backwards-compatible.

[jrochkind]

ah, okay, I guess I misunderstood. I thought :add_field_configuration_to_solr_request => true, was no longer supported as configuration. If it still is, my mistake. (If it's not, then that's what's not backwards compatible about it)

[cbeer]

Supported, yes, but deprecated. I don't think applications are changing that configuration directly, though.. we want them to use config.add_field_configuration_to_solr_request! instead.