Monday, September 28, 2009

Tired of the restricted CoreSearchResults Web Part? Write your own!!!

Ok, I need to rant a little bit before being useful.

I'm quite the Microsoft fan. SharePoint and the .NET Framework(s) pays the bills. HOWEVER…the official documentation is beyond sub-par. This project has reintroduced me to, what I've come to call, The Microsoft Masochists' Gauntlet. I haven't made this trip more than when I'm working with advanced SharePoint functionality. Let's just say I have plenty of scars and bruises from this activity. I just wish I knew what the safe word was every time I had to face it.





"What could it be?…DOCUMENTATION!!!"

*pow* *smack*


*bam* (unconsciousness consumes me here.)

Ok, back on topic.

This project was to replace the current search functionality provided by Ontolica (not a bad solution, just wasn't doing the job anymore) and replace it with an Advanced People Search (I'll call it APS from here on out) page that includes 7 search fields and wildcard functionality.

I started with the MOSS Wildcard Search Web Part created by cdog at CodePlex. It inherits from the CoreResultsWebPart class. It's a great part for simple wildcard search. I tweaked it to handle multiple search parameters with little difficulty.

There were two features that were lacking. First, I couldn't find a way of getting the total number of results returned. With most search results, you want to know the size of the dataset. Second, since it inherits from CoreResultsWebPart, the items per page were limited to a max of 50. This hindered large datasets that needed to be exported to Excel.

Well, the Excel issue I'm still dealing with, but I found a solution to the actual problems. While cdog's project uses the CRWP and FixedFullTextSqlQuery, I created a SharePoint WP (MS.SP.WebPartPages.WebPart…probably would have been fine to use an ASP.NET WP, too) that used the FullTextSqlQuery.

The FullTextSqlQuery has a few useful properties:
  • RowLimit: Sets a limit of rows per page. I created a webpart property where this could be set.
  • QueryText: SQL query. I built this with another function that parsed my querystring search parameters into the query.
  • ResultTypes: Enum that filters different result types. ResultType.RelevantResults was what I used. There are others for Best Bets and High Confidence among others.
When you execute the FTSQ, it returns a ResultTableCollection object. The tables in the collection are the ResultType enum values. From there, I did a bunch of XML stuff to attach XSL to it to "make it pretty."

So, that averted the paging max of 50. However, the total number of results returned still isn't accurate. I assume I could get the full recordset and do a count, but that just seems like extra work. The RTC object has a totalRows property, but it's just an estimate. With small sets, it's pretty accurate. I don't remember where it started missing the actual count, though. Oh well, a simple "Estimated total results: ###" worked just fine. :p

Code will be available shortly.

Mistress SharePoint left me battered and bruised from this experience, but it was a good outcome.

PS. These words are also not safe words: Apple, Mac, iTunes, iPhone, iPod. Ha!

No comments:

Post a Comment