Why the Enterprise Search Web Parts are sealed

I can’t claim to know the real political reasons behind this, which according to Corey Roth’s blog post last December is because “it’s by design”. In my mind “by design” is not a real reason.

For non .Net programmers, a sealed web part means that you cannot inherit from it, doing your own customizations.

So, why are they really sealed?

After investigating the code of the web parts with Reflector (more on that later) I have found that a lot of functionality is hard coded towards either the internal SharePoint Search location or the FAST search location. And if compilation hasn’t  played a trick on the length of the functions in these web parts, they are way too long for my liking, often 70+ lines. By depending so closely on the underlying search components they are in many cases useless to inherit from anyways. The parts you would override would need to contain so much logic and code that you might be better off writing your own web part from scratch. Sealing them at least prevents your from inheriting from something which is hard to work with.

In my mind an OOB (out-of-box) web part should be flexible in terms of configuration, and small changes in code if you inherit from it. A common scenario wanted by many is extending the search web parts is to add an asterisk ‘*’ to a search term, executing it as a wildcard. This is possible today with the CoreResultsWebPart, but not with the PeopleCoreResultsWebPart, which actually inherits the CoreResultsWebPart. And if you want to extend it further to support FQL (FAST Query Language), then you are out of luck, because you have to use the KeywordQuery class for that, which is not accessible thru the web part itself.

Let’s look a bit closer at some of the OOB web parts.

CoreResultsWebPart Unsealed Displays the results for a search query in the SharePoint Enterprise Search UI.
PeopleCoreResultsWebPart Sealed Displays the results for a people search query in the Enterprise Search UI, inherited from CoreResultsWebPart.
SearchStatsWebPart Sealed Displays the search query’s statistics in the Enterprise Search UI. “1-10 of 50 results”
SearchSummaryWebPart Sealed Displays the summary for a search query in the Enterprise Search UI. “Did you mean” functionality.

Using Reflector (a tool to decompile .Net assemblies) to find out what happens behind the scenes I have reviewed the actual code in these web parts and the main discovery is that a lot of functions include lines looking something like this:




What this means is that if the data comes from the built-in SharePoint Search or from FAST, then the web part will have certain logic. If the data comes from say an Open Search provider, or a custom provider you have created against a line of business application, then something else happens.

To illustrate the point you can compare the two images below. The first is a search executed against the FAST location, and the second is executed against a custom location, which again calls the FAST location. So both have the same data at hand.

FAST

fastlocation
Custom

customlocation

They both look about the same but with a couple of differences.

In the SearchStatsWebPart it will not render “of 1234 results” unless you use one of the two built-in providers. Even though you might actually have the information and you set it in your code.

In the CoreResultsWebpart, Action Links are not displayed unless you use one of the two built-in providers, meaning you cannot do RSS feeds or alerts against a custom search location, even though it works just fine. Also if you want to show preview thumbnail of Word and PowerPoint you have to execute the query directly against the FAST location if you are using the default XSLT.

Modifying the PeopleSearchCoreResultsWebPart is interesting if you want to add wildcard to the searches, but not possible today. You have to roll your own search web part instead, and pick out the guid’s for the different rank profiles. So instead of configuration, you are forced into development.

SearchSummaryWebPart is much like the Stats Web Part. You can provide the data all you want, but if you want it rendered with this OOB web part you have to execute the search against FAST or the built-in search.

What it all boils down to is this:

If you want to use the OOB web parts, you should also use the OOB search capabilities. Any deviation will force you to write code.

I suspect time ran out for SharePoint 2010, and we can hope for better and more flexible web parts in the next release. Until then we have to rely on our programming skills and roll our own, using time on plumbing development instead of creating great solutions.

This post is cross-posted at Tech and Me.

Article written by

Computer literate and search enthusiast with an interest for sharepoint, coding, and life in general :)

2 response to: «Why the Enterprise Search Web Parts are sealed»

  1. November 14, 2010 at 14:25 | Permalink

    Very interesting read, Mikael. I love the way you pry open the code to find the answers your’re looking for!

    I can see why you want to add wildcards to the people search, as it makes sense to do substring matching. In FAST ESP, substring matching can also be enabled in the index profile. Do you know if that is possible to do in FS4SP?

    Phonetic normalization is also something I would like to have in people search. How would you implement that using the OOB web parts (if it’s at all possible)?

    Cheers,
    Vegard

  2. November 14, 2010 at 20:14 | Permalink

    The things is that people search is not done via FS4SP. It used the built in search of SP2010. And default you can sort on relevance or social distance in the web part. Via xslt you can sort whatever results you get per page on any column, but not across the whole result set.

    However, phonetic search is a default feature of people search, so this helps. And with custom code you can create your own people web part which sorts on lastname instead of relevance.

    Jerry Orman has an excellent post (http://blogs.msdn.com/b/jorman/archive/2010/10/06/custom-search-web-parts-in-2010.aspx) describing the steps to achieve this.

    As for doing more advanced queries (eg. with fql) without rolling my own web parts I did a proof of concept for myself last week which seems to work. I have yet to test it against people search. And it would be fun to implement people search via FS4P, and compare the results with the internal People Search in SP2010.

    It involves code, but instead of putting the custom code in the web part I create a custom “Search Location”. Once I get a bit further I will post some details :)



Leave a response





XHTML: These tags are allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">


OSLO

Comperio AS
Øvre Slottsgate 27
NO-0157 Oslo,
Norway
+47 22 33 71 00
View map

STOCKHOLM

Search Provider Sverige AB
Gamla Brogatan 34
SE-11 120 Stockholm
Sweden
+46 8-21 49 00
View map