Search within a collection

[elizoller]

Islandora/documentation#1275

[elizoller]

https://docs.google.com/document/d/14a2nsMCojl2aIFBlHac6Npb3LXprBFqbddwfyOcXz28/edit

[elizoller]

This has been configured as two different blocks - one that does deep search and one that just goes one level deep. https://github.com/asulibraries/islandora-repo/blob/develop/config/sync/views.view.search_within_collection.yml

[wgilling]

For the MVP, will this only require the browse functionality or also a "Collection View" page as we saw with the UNT site -- compare:
View: https://digital.library.unt.edu/explore/collections/UNTPC/
Browse: https://digital.library.unt.edu/explore/collections/UNTPC/browse/

I'd love to ultimately have both but am not trying to make more than the MVP for that goal -- and could see a "Collection View" page as a near-future enhancement.

[wgilling]

The blocks referenced by @elizoller are not really part of the commits that I made in the "search_collection" branch (while they remain as blocks "Deep Search within collection" and "Search within collection" as well as an exposed block "Exposed form: search-page_1" from that view's page that can still be played with). They display the contents of the search within the block itself.

The approach taken by the latest commit is to have a page (view) "Solr search content (Index Default Solr content index)" that has an exposed field in the sidebar (block) "Exposed form: solr_search_content-page_2".

[wgilling]

Future concerns are

1. subsequent searches should incorporate all previous searching / selected facets
2. how to deal with breadcrumbs for existing filter(s) and selected facets

[elizoller]

just to clarify - we're going to extend/modify the solr search content view provided by islandora defaults instead of rolling our own? is it worth separating the search within collection from the regular search view, or its similar enough to be ok as part of the same view?

if we're going to use all the same view, i'll go ahead and strip out all the previous views and associated blocks and facets that i'd created in favor of this methodology

[wgilling]

sounds good -- the global site search is still part of that view but it is a different page... if you feel that it is best to separate it, I could do that. For that reason, I thought it might be better to have the various search views all controlled under one view (for the parts that apply to "all displays (except overridden)" vs. "this {page_name} display (override)"). Lemme know if you prefer to have them separate.

[elizoller]

i think you're right - that way if we configure stuff like sorting/pagination/etc, it could apply as defaults to all of the pages 👍 so i should review/merge the search_collection branch?

[wgilling]

I think so ... I changed the view path to solr-search-collection/{nid} and reference the 2nd query parameter. I only changed one thing in the context and something minor in the view (I think) as well as how the hook rewrote the path with a str_replace - now that I think about it, the regular expression may be better since there is potential for the $current_path could be a node/* or a solr-search-collection/*.

I feel that it needs a bit of cleanup and a minor adjustment to handle the 2nd path parameter when it comes from either node/{nid} or is a subsequent search coming from solr-search-collection/{nid}.

Another thought that I just had is that when a user clicks on a collection facet for any global search, it makes me think that we may want to have a "Search in Creator" or "Search in Subject" view page... but that's a topic for another repo-dev meeting.

[elizoller]

what are your thoughts on changing the "solr-search" paradigm to just "search" - maybe it's just a pet peeve but i don't really want a user to see a url with the word solr in it if we can avoid it

[wgilling]

I COMPLETELY approve of getting the "solr-" out of the path and subsequently block name. I'll update that as well and then push this before the end of the day.

[elizoller]

awesome! thanks

[wgilling]

need to test this feature against the use case

[wgilling]

The Members view is only bringing in items that have the "Primary Member Of" relationship (field_member_of) and would not display any items when the item is also in a different collection *(which case it would be related via the "field_additional_memberships").

The view could be redone as a "Solr Search Results" view and make use of the "Ancestors" calculated field.

[elizoller]

isn't that what the "Search within collection" view is already doing as a page rather than a block?

[elizoller]

and in fact the members/children block may not even be relevant to our mockups

[elizoller]

unless you're referring to the "Latest Additions" block?

[wgilling]

isn't that what the "Search within collection" view is already doing as a page rather than a block?

Yes, this view is a "Solr Search Results" view. And if the "Recent Additions" has a "Vuew more results" link, it would be able to go to this page, so a new view may not be needed.

[elizoller]

closed with #137