novolocus.com

So I’ve just started customising SharePoint Search results for the first time. It’s an area that I’ve never really touched before, to be honest - I’ve set up the crawling, and that’s the limit. Now I find myself reverse engineering a colleagues code in order to fix it.

Well, from what I can fathom, SharePoint search results actually come from the Search.asmx webservice in the _vti_bin of your site. The results are actually returned as XML, and in the web parts (not sure which ones, but certainly the Search Core Results web part) you then render this XML to HTML via XSLT. (If that means nothing to you, I’m afraid you’ll have to look it up. That concept is a whole can of worms. Maybe even a crate of worms. Anyway…)

An obvious question is, what does that source XML look like. Well, it’s whatever you get back from the web service, and there are various ways of find that, but I found a neat little solution on a post from Tobias Zimmergren’s blog (in fact, it’s an interesting looking series for a search rookie like myself - I think I’ll have to read that). I’ll blatantly plagiarise that in a bit. Basically, his idea was to define some XSLT that just emits the XML unaltered, and then look at what you’re getting back from the search service on the search results page.

So, to test, I copied the normal search results page (_catalogs/masterpage/results.aspx) to give myself somewhere isolated to test in. I went to it - and it was all empty. Not surprising - there were no web parts. I added a Search Core Results web part:

You might want to add a Search Box web part to give yourself somewhere to enter your search terms, though I’m a bit of a geek and was typing directly into the URL of the browser. For example,
?k=barnacles
will search for documents about, um, barnacles.

Fine. Now we need to apply the XSLT. Edit the Search Core Results Web Part:

and edit the XSL:

Blatant Plagiarism alert - Tobias’ XSL was just:

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

Apply it and voila - XML:

Now I can get on with Styling it.

So one of yesterdays posts brought up a question about rendering the link to the current site. This sort of set me investigating.

There are a number of settings you can use with the ASP:SiteMapPath control. One is the RenderCurrentLink option. This defines whether the current location indicator in the breadcrumb should be shown as a link.

(Yes, this screenshot shows other settings - I’ll discuss them in other posts)

Looking at the top 4 rows you can see the effect of the the RenderCurrentLink option - it determines whether the last item is displayed as a link or not.

I’ve written about this before, but really it was just an addendum to another point I was trying to make. It might be worth bringing out as a post in itself.

ASP.NET navigation controls take data from a navigation provider, and render it into HTML. The breadcrumbs used in SharePoint use the one navigation control, but give it different navigation providers…

… the point relevant to whether or not the “> Pages > default.aspx” is displayed in the breadcrumbs is the SiteMapProvider. The CurrentNavSiteMapProviderNoEncode provider doesn’t seem to include the ‘Pages’ bit of the path - hence it is used by the page layouts. The Default.master’s SPContentMapProvider provides a breadcrumb that includes the ‘Pages’.

So, if your page is using a breadcrumb such as…

<asp:SiteMapPath id="ContentMap" SiteMapProvider="SPContentMapProvider" SkipLinkText="" NodeStyle-CssClass="ms-sitemapdirectional" runat="server"/>

… then your breadcrumb will include the “> Pages > default.aspx”. Note that this is the default content of the breadcrumb in default.master. Thus, if you’re creating a brand new page layout, you’ll probably want to override that content using an ASP.NET Content control something like this…

<asp:Content ContentPlaceHolderId="PlaceHolderTitleBreadcrumb" runat="server">

<asp:SiteMapPath ID="siteMapPath" SiteMapProvider="CurrentNavSiteMapProviderNoEncode" RenderCurrentNodeAsLink="false" SkipLinkText="" NodeStyle-CssClass="ms-sitemapdirectional" Runat="server"/>

</asp:Content>

This code defines a content control that overrides the default content for the Title Breadcrumb. It uses the CurrentNavSiteMapProviderNoEncode (nice name!) navigation provider, and so won’t show the “> Pages > default.aspx” bit in the breadcrumb.

So, in short, when you’re creating a new Page Layout, make sure you override the Title Breadcrumb with something that uses the CurrentNavSiteMapProviderNoEncode provider.

So what has Andy been working on lately? Well, lately I’ve been writing an integration between Outlook 2003 and SharePoint 2007. It was all a bit fraught - some of the web services I was using are a bit dodgy, uploading files and metadata as one transaction doesn’t seem to be possible, and everyone always underestimates the effort involved in coping with the metadata about an email. I’ve written an integration between GroupWise 6.5 and Open Text Livelink before now, and again, dealing with the metadata was a bigger effort than browsing the system or uploading the document.

Now, email saving into SharePoint seems to be an overlooked thing. Microsoft have their Exchange 2007 Managed Folders, which can push emails into a SharePoint Records center. Liam Cleary has written his usual high-quality description of setting it up, and the MS Records management team blogged about it in parts I, II, III and IV.

However, a lot of our customers aren’t impressed with this solution. They want to be able to save emails into particular SharePoint Libraries within their usual collaboration environment, rather than just booting them off into a Record Center.

U2U built an Outlook 2007 addin which is very nice - though a bit of a different take. Their approach requires defining the save location up front and mapping to the data, but that then saving emails is dead easy - just drag them into the folder. Nice.

Anyway, this is what I built - I’ll contrast with the U2U offering lateer…

Read more »

Hmm. One of our salesmen called up today with an interesting problem. We’d published some PowerPoint presentations as slide shows (.pps files). If you open one of these, it should just launch PowerPoint into the presentation. However, he was opening them from our website and they were opening as a normal PowerPoint (.ppt) file. That is they were opening ready for editing, not in presentation mode. Weird.

I remembered having seen this before, but a bit of poking around showed that my fix was still in place. Curious. When I clicked on the link to the presentation I got the ‘Download or Open’ dialog thingy:

First off I noticed that the file extension was .pps - good. I tried opening the file - and it opened it as if it were a .ppt file. Weird. So then I tried the other option - I saved it to my local machine and opened it locally. This time it opened correctly - it opened as a slideshow.

Hmm. So, they’re the same file, but something different is happening when they open. I wondered if it was to do with the HTTP headers, but the same difference occurs when the file is being served with the application/vnd.ms-pps or just text/html (we run MCMS 2002 on a IIS webserver but publish as static content to an Apache server. They serve the file as different mime types, but have the same result - Open opens the file for editing and Save and open shows the slideshow).

Next up, I tried the same experiment using Firefox. If you choose to Open the file rather than save it, it opens the slideshow - correctly! And if you save it, well, it saves the .pps file which, again, opens correctly.

So it looks like Internet Explorer will not open a .pps file as a slideshow irrespective of the mime type sent by the server and the .pps extension (and it’s file association in windows). However, if you save the file locally, it will. Weird.

The only thing that I can think is that this is some sort of security feature, but it’s a bit odd - after all, shouldn’t Firefox do this then?

I upgraded the version of Wordpress I’m running recently and I enabled statistics on the blog. It’s been a bit of an eye-opener. My posts on ‘What the heck is going on with SharePoint Breadcrumbs‘ and ‘More SharePoint Breadcrumbs WTF‘ have together more hits that any of my other articles, and both are visited about evenly.

This is pretty interesting. Breadcrumbs should be pretty simple. I mean, we all use them on the web, probably every day, and often without noticing. So how come people are clearly looking up information about SharePoint breadcrumbs? Clearly something is wrong with them.

So this set me thinking - what’s wrong with them? And here’s what I could think of:

• There are two breadcrumbs. You’ve got the Global breadcrumb, and then the PlaceholderTitle breadcrumb. Seriously, how many websites do you come across that have two?
  
• ‘Site’ levels of the hierarchy can appear in one or the other breadcrumb. Depending on whether or not your navigation inherits it’s navigation from it’s parent site, the ‘Site’ links can appear in the global or title breadcrumbs. Thus, there’s no consistency as to where a site appears - if it appears at all! I can see why it’s been built this way - essentially it allows us to ’skip’ levels in the site hierarchy as shown on the global breadcrumb, and it shortens the title breadcrumb. I wonder if this wouldn’t be better facilitated by a ’show in Global breadcrumb’ site setting. Or just show all sites in the path to the site?
• Why is what is shown in the breadcrumbs tied to what is shown in the site’s top navigation? That’s just confusing.
• Having some breadcrumbs in the Page Layout (i.e. in the main content area) and others coming from the master page is just plain confusing.

I don’t quite know what the answer to this is; after all, we need a way to navigate back up the site hierarchy, though we might not always want to allow that. And breadcrumbs could get very long, so yes, maybe we want to skip levels. But I think I’d be tempted by showing all sites in the Global navigation. This would also divorce the breadcrumb from the top navigation settings, and I think would be easier.

And if the Global navigation gets too long? Well, that seems quite possible. In that case, how about a setting on each site to ‘Display in Menu in the Breadcrumb’ to give something like this:

This way you can still have your ‘Main’ sites in the hierarchy, but all levels are still available. Of course, you might want to make it that all the subsites of last ‘Main’ site are always visible irrespective of that setting. I think that would work, and would require less getting used to.

It’s a bit like the Vista breadcrumb in Windows Explorer - but a bit different, which might count against it…

That said, I’m open to thoughts from others! Comment if you’ve got an idea of how breadcrumbs should work!

I’ve just had to write some instructions about how to check if the Office Primary Interop Assemblies are installed - or more specifically, the Outlook ones. I thought that might be useful…

Read more »

So, I’d been asked to look at building a links menus something like this:

I thought that this was quite nice. I wondered if I could make something similar to this using the Summary Links web part - curiously, it’s something I’ve never really used, and I though I remembered seeing that it could show images too. So, I set up some examples… Read more »

Came across something I’d not considered - self referencing lookup columns! I was doing some testing, and this totally caught me out (and caused my Outlook plugin to crash and die).

Basically, this is a Lookup column where the List that it is looking up onto is the same as the list where the lookup column is in use. In our case we had a list called ‘Issues’, and the lookup was a multi-choice look-up called ‘Related Issues’. It would let a user select things from the Issues list. All in all, a perfectly sensible use of a multiple lookup, and one I’d not thought of!

However, this in itself wouldn’t cause my plug-in to suffer an error. The problem was with the data I was getting back from the Web Services I’m using. I use the List Webservice’s GetListContentType method to get information about the Content Type, and I then read the information about the fields. Lookup fields normally come through with an attribute List ; this is the list that’s being looked up onto, and normally it is a GUID. However, for self-referencing lookup instead of a GUID, you get a string ‘Self’‘. Okay, I can’t argue that it’s wrong, but it’s a smidgen annoying that it is inconsistent. Couldn’t it just give me the GUID and let me figure out if that’s the same list? Or use another attribute to denote that it’s a self-reference?

I don’t get why this was built that way.

I keep having to look this up every couple of months. Microsoft support have described how to find out. Read more »