Type-as-you-go Ajax People Search Web Part using SharePoint 2007 Search Services - Part I

In my organization, the SharePoint 2007's built-in People Search web part does not meet our needs:

• Very limited in customizing both the query and the presentation of the results
• No wild card search out of the box
• Not very interactive/attractive: no type-as-you-go, no ajax, slow response, etc.

To overcome those limitations and create a more user-friendly and powerful people search solution, there are generally two options: 1) build your own web part (business logic at server-side) or 2) use the shipped Content Editor Web Part with your customized content (processing at client-side). Here are the pros and cons of the two solutions:

Comparison between Web Part Solutions

	Server-side Processing	Client-side Processing
Pros	Easier server-side code development with C#, eg. SharePoint search API, XML query packet handling, etc Easier testing and debuging with Visual Studio Logging and exception handling ability	Assembly free, easier to deploy and administrate Processing in client, less load/performance impacts Built-in Ajax
Cons	More work in deployment and administration Harder Ajax, have to mix ASP.NET user control and jQuery Processing in server, potential load/performance impacts	Javascripts harder to test, debug and maintain Harder logging and exception handling

The traditional server-side SharePoint 2007 web part development is actually easy, if you are using the WSPBuilder with Visual Studio 2010. There are quite a few good articles about how to do that, eg. Developing SharePoint WebParts using User Controls and Web Applications by ggalipeau. Some of the contents are a little outdated, but the steps are still applicable. The new layout in Visual Studio now looks like this:

Be careful there are a few catches though, especially the WSPBuilder 1.0.6 generated codes contain some defects. Eg. in xxxReceiver.cs, you have to comment out all contents in FeatureActivated() as SPFeatureReceiver doesn't have FeatureActivated() method. The first line of FeatureDeactivating() this.FeatureDeactivating(properties); must also be removed as this recursive calls will bring you a stack overflow.

Other than those small bugs, WSPBuilder really helps you a lot in focusing on your business logic, and takes off the pain of generating .wsp web part, packaging and deployment, etc. However, as indicated in the above comparison table, the ASP.NET user control was not born with Ajax functionality and the prerequisite of a local SharePoint instance for integration with the development tools is too heavy and dulls the web part development and testing. Well, if you were a Java developer, probably this would remind you of those similar/painful EJB 2.1 days :-)