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

After prototyped and compared both solutions, I found that Content Editor Web Part(CEWP) + Javascript seems more suitable for our needs. It's not only more lightweight, interactive and flexible, but also less administration overhead. The product looks like this:

Here is the design diagram:

Pure Javascript and HTML stuff wrapped in a SharePoint CEWP. The core component here is MyXslt transformer, a small Javascript library I released to transform the search service result (XML) into HTML elements. Below is a list of libraries I used:

Javascript libraries

jQuery	1.5+
MyXslt	XSLT transformer that transforms the search service result XML directly into HTML elements
jQuery UI	UI for dialogs
QTip	jQuery plugin for tip style people's details
Highlight	jQuery plugin for keyword highlighting
MyImgScale	jQuery plugin for Image scaling

The solution layout (for commercial reasons, the full source code is not published at this stage):

PeopleSearch
    +---.hg
    +---clientSideSolution
    |   +---cewp
    |   +---release
    |   +---standalone
    |   +---unitTest
    |   \---_layouts
    |       \---1033
    |           +---images
    |           +---js
    |           +---styles
    |           \---xslt
    +---PeopleSearchWebpart
    +---data
    +---script
    +---UnitTest
    +---UserControlTest
    +---WebTest
    +---LoadTest
    \---TestResults

Another thing worth mention is that the load testing results (see above, using Visual Studio 2010's built-in load testing tool) showed the application was very responsive too.

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 :-)