Abstract: As many SharePoint developers know, from SharePoint 2013, there are several search type of web parts we can use to implement a custom search solution by using SharePoint search engine. Search box web part and Search result web part are frequently used for this type of solution. For typical scenarios, we usually create a search page layout with at least one search box web part and at least one search result web part associated with it on it. Different from this scenario, this article will illustrate how to utilize these two types of web parts to implement an accurate search solution. We will add some drop down lists onto the page to filter content by the options the user selects from the drop-down lists.
1. Introduction
As a rule of thumb, we usually create a search page layout, then add a search box and a search result web part, which is a simple search solution. We can enter some text in the search input box, then trigger the search, the search result web part will show the results containing the keywords.
But if we want to search site content by a specific property, some SharePoint developers will say it is very easy to reach this goal by using KQL language.
From the technical point of view, this is correct. But for some common users who are not familiar with KQL language, this is impossible. So we should provide some friendly user interface for them to filter out what they want (such as, drop down list, radio button, checkbox, etc.).
For our scenario, when Bus Lines is selected, the City filter is shown and we show the items in the specific library that are from that city. When Metro Lines is selected, we show drop down filters for country, state, and city we only show items that match the current country, state and city filters.
2. Insert one search box web part and two search result web parts to the page
- Insert a search box:
- Insert a search result web part for Bus Lines and Metro Lines tab:
3. Programmatically connect search box to search result web parts.
- Export search box web part.
- Open search box web part, change QueryGroupNamesJson to [‘SearchResult1’,’SearchResult2’].
- Export search result web part 1.
- Open search result web part 1, change QueryGroupName to SearchResult1
- Export search result web part 2.
- Open search result web part 2, change QueryGroupName to SearchResult2
- Finally, we can use CSOM API to add these three web parts to the page we want to use, the search results will be connected to search box web part.
- Hide the search box result web part, we just use the context SharePoint automatically generates for the search box web part.
4. Override OOTB Keyword Query function
The first thing to do is to find out the function where all the properties are set to your search results. All the magic happens in the Srch.U.fillKeywordQuery function. In that function the query text, result source ID, row limits, etc… are set.
To not completely rewrite the fillKeywordQuery function, we are going to store the reference to the original function, and call this at the end.
Open up the custom page layout, the magic is to customize our own version of Srch.U.fillKeywordQuery, as figure 4-1 shows, we use OverrideSearch function to gather filters user select from the drop down lists on the search page, then set query template, finally trigger the original keyword query function.
The key point is use JQuery to gather the filter values and apply them to query template. You can also change search result source dynamically by calling dp.set_sourceID(“#Source ID#”);
Now, the code should look like this:
Note: the managed properties mapped with crawled properties must be used in query template.
Conclusion
When you finish all the steps we introduce, you will get a whole accurate search solution, which gathers filters the user selects in the drop-down list and overrides the query template, get the accurate results you want.
