DeviantPoint

I was writing a custom workflow activity for SharePoint Designer today (a pretty cool custom activity, if I do say so myself, which I'll post in a few days) and on my custom activity, one of the settable fields I have happens to be the last word in the sentence:  

So I went to go set the field and this is what I get:

Whenever I went to set the field, the hover action over the activity added a drop down button to the end, thereby making the field impossible to set. Anyways, I'm just going to change the sentence but I thought it was pretty funny and wanted to share it.

While there have plenty of things that people don't like about Windows Vista, one of the features I do like and I think is underappreciated is the new breadcrumb:

Unfortunately in SharePoint, the breadcrumbs don't work like this. There are no submenus. Lucky for us, it's pretty easy to create a breadcrumb that functions this way. Here's how:

Creating the web control

The first part we'll need is a web control that will render the markup. The web control I created is simple and straightforward. Only two public properties are available: SiteMapProvider (string) and NodeSeparator (string). The SiteMapProvider property is used to specify the named site map provider from the web.config file to use to build the breadcrumb. The NodeSeparator property is used to specify the character(s) to use to separate each item in the breadcrumb (like the sideway triangles in the screenshot above). By default, this is set to the '>' character. Also, this property will only be used if the breadcrumb item doesn't have any sub-items; if it does, then a clickable image like the one above will be displayed instead. Lastly, the breadcrumb's submenus will only go one level deep (like Vista's). So there won't be any "submenus of submenus".

The rendering logic takes place in the RenderContents(HtmlTextWriter) method. First, we get an instance of the SiteMapProvider object that has the same name as the one specified in the control's SiteMapProvider property. Then, using the provider, we traverse our way up the site map from the current page (specified by the SiteMapProvider.CurrentNode property) until we get to the top of the site map. While we traverse up, we will collect the nodes that we passed in a Stack<SiteMapNode> collection:

Once we've reached the top, we then pop the nodes out of the stack. Each node will be represented as a list item (li) in an unordered list (ul). If the node has any subitems, then we will render a clickable image and unordered list that is a child of the list item:

This is the typical html markup that is rendered by the breadcrumb control:

That is pretty much it for the web control. The next parts we need to build are the CSS and the JavaScript.

CSS and JavaScript

I won't bore you with the details of the CSS since it's available in the zip file below but the most important things with the CSS are: making sure the breadcrumb items are displayed inline and making sure the submenu uses absolute positioning and has a z-index that will place it on top of any other element that is going to be on the page.

Now for the UI magic to happen, we need a little client-side code. Here again, I use my new favorite client-side library, jQuery. The client script primarily consists of three event handlers: an event handler for the click event on the image, an event handler for a submenu item's hover event, and an event handler used to handle clicks anywhere else on the document.

The click event for the image is used to show/hide the corresponding submenu. It will also make sure that no other menu is visible besides the one that corresponds to the image that was clicked. Finally, it will toggle an appropriate image to use, depending on whether or not the submenu is visible or hidden:

The hover event handler for each submenu item will take care of making sure the item is highlighted properly. The highlighting we will use is the same highlighting used by the top navigation menu:

Lastly, the click event handler for the document will make sure that if the user clicks outside of the breadcrumb, any visible submenu will be hidden:

Putting it all together

So now that we've built the components, it's time to put it all together. First, add the breadcrumb.css file and breadcrumb.js file in a document library or folder in the SharePoint site collection. You also need to place the jQuery javascript library in a document library/folder (note: I used jQuery version 1.2.6 for this).

Second, you need to deploy the assembly 'DeviantPoint.SharePoint.Web.UI.dll' to the Global Assembly Cache (GAC) and then reset IIS.

Third, in order to be able to use the web control we developed, you need to add an entry into the SafeControls section of your web.config file:

Lastly, you need to modify your site collection's master file by first registering our custom assembly:

Then you need to add a reference to the css and javascript files we are using:

Note that in this case, I put 'Breadcrumb.css' in the default Style Library document library. I put the javascript files in a folder I created with SharePoint designer called scripts. Also, make sure to place these lines right before the closing 'head' tag in the master file.

Lastly, we need to place the breadcrumb control in an appropriate spot on the master page where we'd like the breadcrumb to appear:

In this case, I actually replaced the default global breadcrumb that comes out of the box with my own breadcrumb. I also used the GlobalNavSiteMapProvider because that site map provider will have all of the nodes for the site collection.

Results

Here are some screenshots of the new breadcrumb in action:

See? Not too difficult!

Files

In the zip file below, you'll find the assembly that needs to be deployed to the GAC, Breadcrumb.cs, breadcrumb.css, breadcrumb.js, and deviantpoint.master. Deviantpoint.master is just the out of the box master with all the changes to the master file I specified above. You will need to download jQuery v. 1.2.6 yourself.

DeviantPoint_Breadcrumb.zip (11.12 kb)

I had to configure SSO on a MOSS farm with split back-to-back topology with the Web Front Ends (WFEs) in the perimeter network belonging to one domain and SQL Server in the internal network belonging to another domain (there was a trust relationship defined between the two domains). All the service accounts, farm accounts, and database access accounts being used came from the internal domain.

When I tried to configure the SSO service (ssosrv.exe) to use an account from the internal domain, I would get the following error:

A Single Sign-on error has occurred.  Please contact an administrator.  Details: The network path was not found.

There would also be a corresponding entry in the event log like this:

User internaldomain\internaluser failed to configure the single sign-on server. The error returned was 0x80630005. Verify this account has sufficient permissions and try again.

The account used absolutely had sufficient permissions. It met all the criteria specified in http://technet.microsoft.com/en-us/library/cc262932.aspx for the ssosrv.exe service account. I tried and re-tried with other accounts, making the account a domain admin, giving it every SQL Server permission known to man (jk) and it still didn’t work. I even manually created the SSO database myself and ran the SSO schema script myself and manually added permissions to it but I still couldn’t get SSO configured in Central Administration. Actually, I had ruled out issues with SQL Server permissions earlier because when I checked the SQL Server logs, there weren’t even any log entries for login failures. So I sort of came to the conclusion that something else was happening on the WFE before it even got to the database.

After struggling with the configuration for a while and looking at many error log entries, I finally got it configured. Looking at the ULS logs actually helped me resolve the issue because I noticed the following entry:

Net{User|Group}GetInfo said Account {internaluser} does not exist   

What a strange error. Clearly, SSO configuration was attempting to use the command-line command NET USER internaluser to get information about the account being used by ssosrv.exe. But issuing that command goes against the current domain of the machine, which in this case was the domain of the perimeter network and not the internal network domain where this account really came from. By switching the account used by ssosrv.exe to an account that instead came from the perimeter domain and adding that account to SQL Server (and making sure it conformed to the criteria as outlined in the article above), I was able to successfully configure the SSO.

Just another example where the error displayed hardly gets you down the right path.