Enterprise Search Web Parts are still Sealed! Unseal them!
-
Wednesday, December 09, 2009 9:48 PM
I am pretty passionate about Enterprise Search and with MOSS 2007 I saw customers really struggle because wildcard search was not offered out of the box and most of the web parts in Microsoft.Office.Server.Search.WebParts are sealed. Luckily, the most important one CoreResultsWebPart was in fact not sealed and I was able to hack together a wildcard search solution by inheriting it and using some hacky reflection. Since SPC09, we’ve been hearing “the search web parts are no longer sealed”, this unfortunately is not true at all. What they mean to say is that they have added a couple of override to CoreResultsWebPart that allow you to affect the query going in and the results going out. This is a nice win, but there is still more desired.
It took me asking a lot of people at SPC09 to finally get a straight answer. It was in the session, Customizing Search in SharePoint: Building Great Sites with Search, where I asked Harneet Sidhana at the microphone to get the story on why most web parts are still sealed. The answer? The remaining web parts are currently still sealed by design. The audience “booed”. Seriously, they did. I then asked to have the web parts unsealed and the audience applauded.
Let’s take a look at the web parts between MOSS 2007 and SP2010 Beta 2 and see what is sealed.
Web Part MOSS 2007
SP2010 Beta 2 AdvancedSearchBox Sealed Sealed CoreResultsWebPart Unsealed Unsealed FederatedResultsWebPart Unsealed Unsealed HighConfidenceWebPart Sealed Sealed PeopleCoreResultsWebPart Sealed Sealed PeopleRefinementWebPart Unsealed QuerySuggestionsWebPart Unsealed RefinementWebPart Unsealed SearchPagingWebPart Sealed Sealed SearchStatsWebPart Sealed Sealed SearchSummaryWebPart Sealed Sealed
TopFederatedResultsWebPart Unsealed Unsealed Looking at this list, I don’t really see anything that has changed from sealed to unsealed. Do you? I will point out that CoreResultsWebPart has always been unsealed, but this is because PeopleCoreResultsWebPart inherits from it. Did you notice that anything built since the Infrastructure Update of MOSS 2007 has been unsealed?
Now I admit, the main reason we wanted to inherit from these controls was to do wildcard search. The Enterprise Search did a great job with the new keyword query improvements and this will be a non-issue now. However, can they really say we will never want to extend their web parts? Are they going to say that they have thought of every possible thing that the web part might possibly do and no one will ever extend it? As a programmer, I don’t think I would ever have the guts to make a claim like that. I know these web parts will require customization in the future. Give us the ability to do it.
I know you might be thinking, “We just wanted to inherit from these web parts because we wanted wildcard search. We have that now.” This is true and I am very thankful. This eliminates the need a lot, but more than likely we might need to make a change to something else though. Want to customize people search? What about best bets or the advanced search box? Most web parts in SharePoint are unsealed, so why are the search web parts sealed?
The PeopleCoreResultsWebPart still being sealed is a huge deal. For one, it doesn’t appear to support the new QueryManager class which means you can’t customize how it does queries or builds the results. I need to confirm this though. Take a look at the forums. They speak for themselves. Fifty results for the term wildcard in the Search forum. I am passionate about this topic because I have seen the needs of my customers. The fact that I might be stuck with another set of sealed web parts for another 3+ years is absolutely scary to me.
So what can we do? Please post a reply in the forum or leave a comment on the blog. We need to let them know our concerns while there is still time to make a change. Please, unseal the web parts. This post is cross posted to my blog.
Corey Roth blog: www.dotnetmafia.com twitter: @coreyroth
All Replies
-
Thursday, December 10, 2009 7:25 PMCorey,
Great post.
Microsoft, Please unseal these webparts. -
Sunday, December 13, 2009 7:46 PMI Agree with Corey.
Microsoft, Please unseal these webparts.
Shah -
Wednesday, December 16, 2009 3:35 PMAs developers we need to be able to provide SharePoint-based solutions based on our customers' requirements. Having these web parts unsealed would help immensely!
-
Friday, January 01, 2010 5:20 PM
Hello Corey,
Thanks for being actively involved with Enteprise search and for the detailed analysis of the search web parts in 2010.
Based on feedback from SharePoint 2007 around inability to extend our out of the box experience, the enterprise search team looked into providing an infrastructure that can be used by our partners and customers to easily extend the search experience without requiring to rewrite the entire search page from scratch. As part of this initiative our strategy has been to
1. Keep the key Web parts that form our infrastructure – core results, federation and refinement – unsealed. They form the foundation of our experience and provide most of the functionality we think customers would want to extend.
2. Provide an easy way for the our customers to not only extend the search experience by extending the out of the box web parts but also to be able to create simple web parts that can work with the web parts on the search page.
I will like to emphasize the importance of point 2 above. As you might already know, search web parts in SharePoint 2007 used internal interfaces to communicate with each other and submit the query to the search system. In SharePoint 2010, we have changed the communication model between the search web parts so that they use public interface (called the SharedQueryManager) which can be used by our customers and partners to not only easily extend the unsealed web parts (without any reflection) but also write new web parts that can work with web parts on the search page. There is a single SharedQueryManager object per search page that is both shared by all the synchronous web parts and is also accessible through public methods.
For example, if you want to create a custom paging control, you can simply write a new web part use the properties of the SharedQueryManager to either read the current set of results returned or set these values to request for the next set of results. Since the SearchPagingWebPart is implemented for a specific design we believe that there is little benefits for the community to inherit from the web part as compared to writing a new web part. Similarly the search stats web part and Search Summary web part are implemented for specific design.
The PeopleCoreResultsWebPart as you pointed out is inherited from the CoreResultsWebpart. This is still sealed in SharePoint 2010, because PeopleCoreResultsWebPart is an extension to the CoreResultsWebPart which can be easily achieved by extending the CoreResultsWebPart and using the SharedQueryManager object to set the right set of properties pertaining to people queries.
If you have any questions or concerns, please feel free to contact me.- Marked As Answer by Thomas Rizzo Friday, January 08, 2010 1:58 PM
-
Tuesday, February 23, 2010 3:37 PMI apologize. I got busy on a deployment and never realized it had been replied to. I, of course, am the Enterprise Search team's biggest fan and I appreciate the response. :) I have to say that the SharedQueryManager is a great step in the right direction (although being able to specify and sort order without FAST would be nice).However, I do not agree that the PeopleCoreResultsWebPart should be sealed. As a developer when I seal a class, it means to me "this class is perfect, it does everything anyone could ever possible think of, and no one in their right mind would ever want to extend it". I think that's a pretty bold statement and I have never made it myself. The biggest reason people wanted to extend CRWP or PCRWP in MOSS by far was to add wildcard searching. Obviously, this is a non-issue now, but the fact is we don't know what the community will need to change about their search results screen yet.I just don't understand the refusal to unseal this one web part. I've looked at the code through reflector and there is still a significant code difference between it and the CRWP. I'm sure the community will step up and release a PCRWP that isn't sealed, but why should we have to? All I am asking is to be able to change the query that this web part executes without having to reinvent the wheel. I don't think I am asking too much.I realize that we are pretty much at the end of the product cycle now and there is probably nothing that can be done. I hope I'm not coming across as hostile, because I'm not, but I am frustrated. I know that my clients will ask for customizations of the people search page in which I'll have to give them the same response I did back when wildcard search was an issue.I know this question is going to come up repeatedly over the next three years or so in the forums. I'll always be happy to help the community find a solution that works, at the least I can point them to this post and they can at least understand why it is still sealed.This aside, I am really excited about the new features in Enterprise Search and I can't wait to start rolling it out to customers. Thanks again for your response.
Corey Roth blog: www.dotnetmafia.com twitter: @coreyroth -
Wednesday, March 10, 2010 3:35 AMIs there any way to achieve the following in people search
1) Sort results by Lastname and Firstname
2) Show more than 50 results per page -
Thursday, March 11, 2010 5:23 PMThere could be if the web part wasn't sealed.
Corey Roth blog: www.dotnetmafia.com twitter: @coreyroth -
Tuesday, March 16, 2010 12:20 AMThanks for this post.The project I am working on, the client needs advanced search and the webpart provided out of the box is not good, since the client wants to search and type in search criteria specifically to his business processes. Does this mean that I need to rebuild the whole advanced search web part?I am new to sharepoint so this question may look a bit naive. But I am a bit lost on this topic.
-
Tuesday, March 16, 2010 9:19 PM
Given the number of people still commenting on this post, it really shouldn't be marked as answered because the community is far from satisfied.@japac74Yes, since the Enterprise Search team insists on keeping the AdvancedSearchWebPart sealed, you get to rewrite all of its functionality. Luckily, it's not that difficult to create a custom advanced search web part. Here are my instructions on how to do so. This will work with MOSS 2007 or SharePoint 2010.Thanks,
Corey
Corey Roth blog: www.dotnetmafia.com twitter: @coreyroth- Proposed As Answer by obhayes Monday, July 12, 2010 2:43 PM
-
Monday, July 12, 2010 2:43 PM
I am in full agreement with Corey and Im very frustrated with the fact that the people search webparts are sealed. People search / social interaction is one of the big selling points of sharepoint 2010, so how frustrating is it that you buy the product and then find you have to do further development to achieve simple things?
Has anyone actually done what Harneet mentioned..."extending the CoreResultsWebPart and using the SharedQueryManager object to set the right set of properties pertaining to people".
Is it easy? Has anyone created any technical notes / gotchas on this? Do all the other webparts like the people refiners continue to work ok?
-
Monday, July 12, 2010 2:46 PMNot that I know of yet. It's on my to do list. I took a look at the PeopleSearchCoreResultsWebPart in reflector and there is quite a bit of difference between it and the CRWP. It can probably be done, but I'm sure it's going to take a bit of work.
Corey Roth blog: www.dotnetmafia.com twitter: @coreyroth -
Monday, March 07, 2011 4:10 PM
Corey,
Thanks for the instructions. I find myself in the same boat where a client needs a customized advanced search web part and I would love to be able to extend the advanced search to achieve this. Hopefully building a custom advanced search web part will be able to meet our needs.
-
Thursday, May 19, 2011 5:47 AMHarneet, It is universal known that sealed classes are the developer behavior of not allowing anybody to build on top of it. But Microsoft is a vendor of the technology. We are the developers to provide solutions to end customers. I feel like not even one class in entire Microsoft should be sealed. We always want to extend it to customer comfort. It looks like Microsoft wants their mark in providing out of the box web parts. Any vendor can NEVER EVER provide the ultimate needs of customer. That is where we come into the picture. For my customer it happened that I got to sacrifice all the web parts provided for PEOPLE. We made custom web parts for the people for the reasons like new brand applied, people search results ordering by first name, job title etc and most importantly people results exact count. If the people core results web part was not sealed lot of my work might have simplified. I bet whoever got the bugging customer might have felt the extreme pain with search web parts. There is no point defending sealed web parts. PLEASE UNSEAL them.
-
Tuesday, January 24, 2012 9:24 AM
I want to keep this post alive, cause the PeopleCoreSearchResults is causing me some problems.
A few months ago I extended the CoreSearchResults with no problems, and now I thought I could do the same with the PeopleCoreSearchResults but I found an ugly surprise. It is sealed as everyone is saying here.
My problem is that I want to filter some users/people from the search results (and I can't use scopes, because my filter consists in excluding users with a null value in the 'Department' property from the user profile, and you cannot create a rule with a null/empty/quotes value in the scopes because it will not work).
Is there an easy way to do it?
Thanks

