Display thumbnail in search results. #316
Conversation
Fixes ndlib/planning#339 Refactor representative object Refactoring thumbnail not to fetch from fedora each time Remove representative_object method as its not needed Removing duplicate view Refactor Generic File to be represented Make the first file as representative file
|
What's the delta between this and the native thumbnail support in Blacklight? Is there anything here that should get pushed upstream? |
|
@cbeer we're not familiar with the native thumbnail support of Blacklight, so I don't think we can answer. However, I'll explain what is going on to see how that jives with your understanding: Most objects (Works and Collections) in our catalog controller response do not have files directly attached to them. Instead they have multiple GenericFile objects associated with them. Each GenericFile has a file and derivatives (e.g. thumbnail). A catalog object has a representative – a to_param for one of its GenericFiles. That representative is then used for the thumbnail. |
|
@cbeer - We are storing the NOID of another file, so what would we need to do for the thumbnail? We also are making use of customized partials for each SOLR document, which likely won't be a problem, but we'd need to see how they play with Blacklight's output. |
…arch-results Display thumbnail in search results.
…vera-deprecated#318-samvera-deprecated#316-samvera-deprecated#320-hailstorm-fixes Fix Hailstorm vulnerabilities
Fixes ndlib/planning#339