Visies en best practices. Lees het hier.

Custom styling and transformation for your search results are a great way of fitting the results into the general look & feel of the application and adding relevant metadata in one big swoop. Unfortunately, debugging the XSLT is rather limited. A quick overview:

• if your XSLT contains a syntax error, SharePoint will load the previous version of the XSLT
• in order to get the popup in which you can paste your XSLT, you’ll need a number of page reloads which is a hassle in itself and might be cumbersome depending on your system specs
• XSLT error messages are hidden, only a generic error with the mapped properties might be displayed (related to the columns)

If you need to do a complete rework of the style, there’s a simple trick that I noticed many SharePoint developers don’t know about that will potentially save you a lot of time and effort.

Test your XSLT outside of the CoreResultsWebPart!

By extracting the XML for search results from the CoreResultsWebPart and linking the XSLT stylesheet to it, you have access to error details from the XSLT parser and can avoid many often slow loading SharePoint page reloads. Two simple steps will allow you to do this.

1. Extract the XML from the CoreResultsWebPart

Using the following XSLT snippet (which every other SharePoint blogger has posted at some point; I got from MSDN this time around) to style the search results, the webpart dumps the generated XML on th screen. Simply copy and paste the XML code into a file on your local machine and step 1 is finished.

<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>
<xsl:template match="/">
<xmp><xsl:copy-of select="*"/></xmp>
</xsl:template>
</xsl:stylesheet>


The XML results should look similar to this:

<All_Results>
<Result>
<id>1</id>
<workid>5015</workid>
<rank>87098240</rank>
<title>TEST</title>
<author>Frans</author>
<size>0</size>
<url>http://server:2002/default.aspx</url>
<urlEncoded>http%3A%2F%2Fserver%3A2002%2Fdefault%2Easpx</urlEncoded>
<description></description>
<write>29-9-2011</write>
<sitename></sitename>
<collapsingstatus>0</collapsingstatus>
<hithighlightedsummary><ddd /> </hithighlightedsummary>
<contentclass>ContentClass</contentclass>
<isdocument>False</isdocument>
<picturethumbnailurl></picturethumbnailurl>
<serverredirectedurl></serverredirectedurl>
<Result>
<All_Results>


2. Link your XSLT to the XML

Paste your XSLT code into a file and store it in the same folder as the XML file. Now all we need to do is link the stylesheet file to the XML file. The snippet to accomplish this looks like this:

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="searchresults_styling.xslt"?>


More info about this on w3schools. And that’s it. Now just open the XML file in a browser and start styling and transforming the search results using real data!

Note: since the XSLT most likely won’t be generating a full HTML document styling you’ll most likely be lacking CSS and such. The structure however will be just fine.

Het CoreResultsWebPart in Sharepoint 2010 is een rijke feature. Out-of-the-box kan het onwijs veel, biedt het veel configuratiemodelijkheden en kan het de meeste scenario’s zonder problemen aan. Maar, het CoreResultsWebPart is bedoeld voor traditionele zoekimplementaties. Zodra je meer “search driven” oplossingen gaat implementeren, loop je snel tegen de beperkingen aan. In dit blog belicht ik één van de vele aspecten van search driven oplossingen: de noodzaak tot custom sorting.

Wat? Waarom?

Sharepoint search geeft je weinig opties tot het sorteren van je zoekresultaten. Vanuit de gedachte dat het zoekresultaten zijn en je dus de meest relevante opties bovenaan wilt hebben, is dit natuurlijk prima. Maar wat doe je als je het nieuws uit alle sites in je sitecollecties wilt tonen, relevantie wordt dan opeens publicatiedatum. Wat doe je als je een productsuggestiefunctie voor een webshop bouwt? Dan is relevantie een stuk complexer dan tekstuele overeenkomsten en wil je zelfs direct invloed kunnen uitoefenen op de resultaten. Dit is het topje van de ijsberg met betrekking tot search driven applicaties en in dit blog licht ik een simpel voorbeeld toe van hoe je dit voor elkaar kunt krijgen in Sharepoint 2010.

Allereerst: FAST

FAST Search kan dit soort operaties (en meer) OOB. Het grootste voordeel van FAST werkt helaas in het nadeel.  FAST is een beest van een applicatie en dat leidt tot een behoorlijke footprint, licentiekosten, expertise en consultancy en stevige hardware vereisten. Dat maakt FAST niet geschikt voor alle implementaties, het is al snel een kanon om een mug dood te schieten.

Dus je kunt niet altijd FAST inzetten, maar wilt wel beschikken over custom sorting

Dat kan! Maar het kost wel wat werk. Het CoreResultsWebPart is niet sealed. Door een webpart te maken dat overerft uit CoreResultWebPart heb je de mogelijkheid om het gedrag van je zoekapplicatie te beïnvloeden. In dit specifieke geval overriden we de DataSourceView voor de resultaten. Dit doen we in 3 stappen: eerst maken we een overriding class voor CoreResultsWebPart en specificeren we een nieuwe DataSource.

public class CustomSortedResultsWebPart : CoreResultsWebPart {

   protected override void CreateChildControls() {
      base.CreateChildControls();
   }

   // override the DataSource to allow overriding the DataSourceView
   protected override void CreateDataSource() {
      this.DataSource = new CustomSortedResultsDataSource(this);
   }
}

Vervolgens geven we in deze custom DataSource aan dat we een custom CoreResultsDatasourceView willen gebruiken.

public class CustomSortedResultsDataSource : CoreResultsDatasource {
   public CustomSortedResultsDataSource(CoreResultsWebPart ParentWebpart) : base(ParentWebpart) {
         //create the View that will be used with this datasource
         this.View = new CustomSortedResultsDataSourceView(this,"CustomSortedResults");
      }
}

En tot slot geven overriden we in de custom CoreResultsDatasourceView de AddSortOrder om onze eigen sorteren te tonen.

public class CustomSortedResultsDataSourceView : CoreResultsDatasourceView {

     public CustomSortedResultsDataSourceView(SearchResultsBaseDatasource DataSourceOwner, string ViewName) : base(DataSourceOwner, ViewName) {
         //make sure we have a value for the datasource
         if (DataSourceOwner == null) {
             throw new ArgumentNullException("DataSourceOwner");
         }

         //get a typed reference to our datasource
         CustomSortedResultsDataSource ds = this.DataSourceOwner as CustomSortedResultsDataSource;

         //configure the query manager for this View
         this.QueryManager = SharedQueryManager.GetInstance(ds.ParentWebpart.Page).QueryManager;
     }

     // Add a custom Sort Order for the results
     public override void AddSortOrder(SharePointSearchRuntime runtime) {

         #region Ensure Runtime
         //make sure our runtime has been properly instantiated
         if (runtime.KeywordQueryObject == null) {
             return;
         }
         #endregion

         // use the following to get a handle to the CoreResultsWebPart, allowing this webpart to be configurable though properties etc
         //CustomSortedResultsWebPart webPart = DataSourceOwner.ParentWebpart as CustomSortedResultsWebPart ;

         // remove any other sorted fields we might have had to ensure our custom sort
         runtime.KeywordQueryObject.SortList.Clear();

         // configure the sort list with sort field and direction
         runtime.KeywordQueryObject.SortList.Add("MyCustomField", SortDirection.Ascending);
     }
 }

Ruim 600 mensen, voornamelijk vanuit communicatie en ICT, verzamelden zich in Media Plaza voor het congres Intranet 2011 om te spreken over onderwerpen als sociaal intranet, governance, cloud, Google Apps, Yammer, mobiel en apps. Wat waren de 5 belangrijkste lessen van de dag?