Wednesday, May 25, 2011

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

jQuery1.5+
MyXsltXSLT transformer that transforms the search service result XML directly into HTML elements
jQuery UIUI for dialogs
QTipjQuery plugin for tip style people's details
HighlightjQuery plugin for keyword highlighting
MyImgScalejQuery 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.

Tuesday, May 24, 2011

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
  1. Easier server-side code development with C#, eg. SharePoint search API, XML query packet handling, etc
  2. Easier testing and debuging with Visual Studio
  3. Logging and exception handling ability

  1. Assembly free, easier to deploy and administrate
  2. Processing in client, less load/performance impacts
  3. Built-in Ajax
Cons
  1. More work in deployment and administration
  2. Harder Ajax, have to mix ASP.NET user control and jQuery
  3. Processing in server, potential load/performance impacts

  1. Javascripts harder to test, debug and maintain
  2. 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 :-)

Tuesday, May 3, 2011

MyXslt v0.2 released

In my previous blog, I provided a temporary fix for jQuery XSLT plugin. However, it is neither complete nor correct due to the plugin's lacking of callback interface during its asynchronous XSLT processing. From David Flanagan's excellent book "JavaScript: The Definitive Guide (5th Edition)", I found a pure Javascript solution and decided to enhance it to suit my needs.

The potential usage of this small Javascript library is calling any web services that return XML then transforming it directly to HTML elements by XSLT. In my case, I created a customized People Search web part in SharePoint 2007 as a replacement for the built-in one, and made complicated search easier, more flexible and interactive. This web part doesn't need any server side programming as it's pure HTML + Javascript contained in SharePoint's provided Content Editor Web Part. For more information about this web part, please stay tuned.

More information here, downloads and source code.