Table of Contents:
- Business Reason behind this Post
- Think "Filter" = "Search" = "End user won't know the Difference"!
- Connecting your Data View to a Form Web Part
- Clearing, or Resetting the Search Results
- Adding Wildcard Searching
- Removing Case Sensitivity on Searches
- Conclusion
Business Reason behind this Post
You may be thinking why in the world would you want to search a SharePoint list using a Data View Web Part? Well the answer to that question revolves around how much control you may want on the search results. Consider these three business cases:
- You only want to search on one column in the list, rather than all the (indexed) columns.
In the settings of a SharePoint list, you can set what columns are in the search results when a user performs an out of box search on the list (image below). Well if you only "index" one column, you'll only get search results on one column, so this bullet is nullified. But what if you have selected several columns to be indexed, perhaps for performance benefit reasons, but you still want to provide to your end users the ability to search on only one of those columns and not all of them? If they go to the out of box search, they may get results from other columns which might not be desirable. With a data view web part we can trim a search down to one or many columns, as our requirements dictate.
- You want to perform a search on multiple lists, but not all the lists on a web.
If you go to a site in SharePoint you'll see the out of box search. You can do a search on that site (image to the right) to search on all the content within the site. However, say there are 10 lists on the site, but you want to give you end users the ability to search just three of the lists and not all of them. You can do this with a Data View search by creating a Data Source off of a "merge" of the desired SharePoint lists, and searching on that "merged" data.
- You want to have a very specific Look and Feel that the search results use.
The Out of box search results can be customized to some extent, but in the end a Data View with the actual Data Source available to it will be a more robust solution if your user interface needs heavy customization. Consider the difference between search results within the figure just below. On the left you'll notice the out of box results, and on the right you'll notice a Data View Web Part. The web part shows a search off just the "Project Name" column in a list of Projects. You'll notice the UI looks very different than the out of box results, and this UI can be customized to meet your requirements. Notice also the out of box web part shows results from all sorts of places because the search was performed at the site level. Using a Data View can help make your site more usable.
Think "Filter" = "Search" = "End user won't know the Difference"!
Now that I've gotten you stoked about using Data Views to search on list data, I must share the "bad news" with you. To implement a "search" with a Data View, you're actually not searching like you'd expect to be, rather you're "filtering" the data. WSS doesn't provide out of box search web parts like MOSS does, so we're left with the Form web part. Essentially what we do to simulate a search experience for the end user is use a Form web part to provide a parameter to the Data View, which uses that parameter to filter down the data and only show the resulting sub set. It's not a true search, but sure feels like it to the end user, and I bet in most cases they would never know the difference!
What we're going to build in this walkthrough is the connection between the Form web part and the Data View. It is implied that you'll have a Data View already built that you want users to be able to search on. Notice how the solution will look in SharePoint Designer:
Connecting your Data View to a Form Web Part
After you have a Data View built out that you're satisfied with, you can add the Form web part to filter ("search") the data. Click on a web part zone, and the web parts pane will appear to the right. Click next a few times and drag and drop the Form web part into the zone.
After I dropped the web part in the zone, I set the Title property to something other than "Form Web Part", as well as set the width to 250px and aligned the text to be centered. Another thing you can do is right click the "Go" button and choose properties. From there you can rename "Go" to "Search".
After which I'm left with a web part looking like this:
Now we need to connect the two web parts and make the search web part pass a filter value to the Data View. To do this, right click the search web part and choose "Web Part Connections…".
Note: if you get an error popup like the one below, you're on a publishing site and you need to save the page, and then try it again.
After you click Web Part Connections, a dialog will appear – leave the default set to provide form values to – and click next:
Choose connect to another web part on this page – and click next again.
Next, select the Data View you want to search, and choose Get Form Values From – and click next:
The next step you need to map what was typed in the search box to a particular field in the Data View's Data Source. On my data source, I have a field called "Project Name". I want to create a way for people to search project names, so I'm mapping the "T1" search box to this project name field – click next:
Click Finish. Click Save in SharePoint Designer.
Refresh the browser page and you'll see the new form web part. Try searching for something!
Now – the rest of this post goes through making what you just built better. You'll quickly notice TONS of nuances – let's take each annoyance one at a time.
Clearing, or Resetting the Search Results
The first thing you'll notice about this system that kind of stinks is the search only seems to work once – where consecutive searches don't seem to return anything. The problem goes back to that fact that we're filtering, not searching the data. So, after we search something, and then search again, what we're really doing is adding a second filter on what was already filtered. So if you get 10 results back from the original search, your second search is only searching those 10 results. Well obviously this is lame, and unfortunately the only thing I could come up with is to add a "Search Reset" link bellow the search box. When clicked, the user is just redirected back to the page they're currently on, thus resetting the filter.
Adding Wildcard Searching
Another thing with this search is that it is an exact match search only. This of course is really not a search because you need to know exactly what to type to get anything back. Take for instance my search term of "Develop Searching System". If I had searched for "Develop Searching" it would not have returned any results. To get this to return something, we need to implement a wild card search.
To implement a wildcard search we're going to use an XSL Contains method to search the data to see if it contains the term, rather than exactly matches it. Follow these 3 steps to convert to a wildcard search:
1. The first thing we need to do is setup a parameter on our Data View. The reason is because if you remember we choose to "Get Filter Value From" earlier, and filter values are exact matches. Because of that we need to load our search term into a variable that can be leveraged in our custom XSL code.
Click on your data view properties icon and choose "Parameters":
Click "New Parameter" and title it something like "SearchTerm". Leave the other defaults, and click ok.
2. Go back to the Web Part Connections interface on the search box, and modify the connection we setup earlier:
Note: you may get that same error message we saw earlier. Save the page and try again.
Click next twice. Change the drop down to be "Get Parameters From":
Click Next.
Set the "SearchTerm" parameter to be that of our search box ID:
Click next. Click Finish.
3. Lastly we need to edit the rows query that the Data View uses. In the Code view, search for name="Rows". Notice the select on that variable contains a query – this is what we need to modify. By default it brings back all rows, but we need filter out the rows that do not match our search term.
After the "/Row", add "[]". Within the [], add "contains(,)". Notice the contains method takes two parameters. The first is the string you're looking in, and the second is the string you're looking for. If the second string is contained within the first, the result is true and that row will be added to the Data View and the search result set.
For me, I want to see if my search term (the parameter we added to the Data View earlier) is present within the Project Name column. Before we did an exact match, but now we will alter the Rows variable to use a contains method, and thereby supporting wildcard searches (some would call it "poor man's" wildcard searching, but it is good enough for me).
Click Save – and search again!
Or better yet!
Removing Case Sensitivity on Searches
Wildcards (more specifically, contains) searching is pretty cool, but what about case sensitivity? If I take the solution we've built thus far, and search for "develop searching" rather than "Develop Searching", we don't get any results back! Obviously we NEED to make our search case IN-sensitive!
To do this, add the following variable directly before the Rows variable:
<xsl:variable name="smallcase" select="'abcdefghijklmnopqrstuvwxyz'" />
<xsl:variable name="uppercase" select="'ABCDEFGHIJKLMNOPQRSTUVWXYZ'" />
<xsl:variable name="searchcaps" select="translate($SearchTerm, $smallcase, $uppercase)" />
Essentially what we're going to do is take our SearchTerm parameter and translate all the lower case values to be upper case. Next, we'll translate the data source parameter in the Rows query, just like how we translated the SearchTerm. Thus, both the data and the search term will be upper case, and our search queries will be case insensitive. The final code looks like this:
Try your search again!
Conclusion
As you can see, you can do some pretty cool stuff with Data View Web Parts. Combined with the Form Web Part, you can really build a nice searching solution that just couldn't be accomplished with the out of box search.
I hope this helps!
Phil