Configuration-driven, "format" specific index and show fields

[cbeer]

We want to be able to show different fields depending on the type of object ("format"). This is possible now by using different templates for each object type, but we might be too lazy if there's a way to support it in Blacklight.

[jrochkind]

To me, putting this in sounds like over-engineering. BL already has too
many back alleys of logic, we ought not to add more, with the
support/maintenance burden they entail.

It's easy enough to do this with different templates, that ought to be
the supported way. If you want a more generalized DRY way, you should
create one yourself for your app -- it's easy enough to do that too.

Different apps are going to have different needs (this particular need
you identify is not one my app has, or is likely to have, because I
generally dont' display from solr stored fields in the first place) --
the right way to handle your apps specialized needs is by writing ruby
code in your app, not making BL logic to handle every possible need.

On 1/15/2013 6:16 PM, Chris Beer wrote:

We want to be able to show different fields depending on the type of
object ("format"). This is possible now by using different templates for
each object type, but we might be too lazy if there's a way to support
it in Blacklight.

—
Reply to this email directly or view it on GitHub
#523.

[jkeck]

Just my $.02 on this (and the disagreement expressed in #522). We provide the facility to render different templates based on a the document_partial_name (or whatever that method is these days). However; we don't have the facility to have separate field configurations for those different partials.

This causes an issue when you have an application that has mixed content. As an example, if we had a solr index w/ mixed content of books and digital images we may want to put information about the "authors" of the items in the same solr field for searching and boosting purposes. However; the digital image's author may be describing a lithographer and the book is describing an author. We would probably want to configure different labels based on the format of the item (not necessarily based solely on the field name).

I understand that we could do this at the application level (and currently we have), however since we provide the facility to have object specific partials having object specific field configurations for those partials seems sensical. It's not like we're adding a feature for one applications specific case, we're discussing this feature to mimic the architecture we already have.

Clearly people will disagree and argue ad nauseam about this, so this is probably where I'll drop my opinion.

[jrochkind]

I still think this is over-engineered and would be better off as local customization for those who need it. shrug.

[cbeer]

I'm not sure what you're complaining about.

Here's the info from the merge commit (should have been on the source commit, oh well:)

Update index_field and document_show_field (and similar) methods to support an optional 'document' argument, which may be used downstream to inject alternative index/show fields based on characteristics of a document.

This patch just has Blacklight pass around the information needed to make those decisions (which, in part, it was already doing using the ivar @document).