It’s never the first thing that I get asked on an engagement. It’s never the burning question in the minds of my customer as they seek out a consultant to help them with SharePoint. However, sooner or later it eventually comes to the topic of navigation. Although the fundamental concepts behind a sensible navigation framework are simple, they are not well understood by developers or designers. This article is designed for both audiences as they seek to make SharePoint usable.
Foolish Consistency is the Hobgoblin of Little Minds
Emerson (who said “Foolish consistency is the hobgoblin of little minds”) is a personal favorite author of mine;
however, he didn’t have to train hoards of users how to use a new interface. There’s definitely something to be
said for creating the kind of navigation that users are accustomed to. In the world of the Web that means
navigation belongs on the top and on the left.
Nearly every non-marketing Web site will follow a pattern with navigation on the top and on the left-hand side.
While what is on the top and left side differs, the fact that these spaces are reserved for navigation normally does
not. So if you’ve got a wild side, or feel like training scores of users, you can move the navigation — otherwise
we’re more or less stuck with the accepted norm.
Please enjoy a free copy of this article, also located on our Gifts page
When you get into modifying site definitions you’ll run into a few interesting challenges. Not the least of which are all of the different versions of a page that you’ll have to update in order to make the whole site to fit together. One of the interesting aspects is the list pages. Each list has it’s own set of pages.
On those list pages are some web controls that control view navigation and another one that controls the related links — both of them are on the left side of the page. If you want to get to one master page without modifications these web controls present a problem. (In other words, I want to manage one aspx page and be able to copy that into each of the files in each of the lists.) Those pesky web controls make that not possible.
However, there is a solution. You can encapsulate the ViewNavigation and RelatedLinks classes in the Microsoft.SharePoint assembly into web parts and use them as web parts. In that way, you can change the left column to a site navigation web part zone and then insert web parts for ViewNavigation and RelatedLinks on the pages that happen to be list pages. Then you can insert your own navigation above or below these standard web controls — and you can swap them out later without having to deal with the “thou shall not modify a site definition after it has been created rule.” (I may have paraphrased that a bit.)
In general it looks like the WebControls in the Microsoft.SharePoint.WebControls namespace will encapsulate well into web parts so you can reuse the built in web controls — even if you want to move to a web part basic design.
As a sidebar, the Microsoft.SharePoint.Portal.WebControls seem to all derive from WebPart so you won’t even have to encapsulate them. All that’s necessary there is to create a DWP file.
The common administrative pages are still a challenge — but it’s getting easier bit by bit to create a cohesive site definition.
By the way, here’s the entire file I used to encapsulate the RelatedTasks web control…
/// Shell for Related Tasks web Control
public class RelatedTasks : Microsoft.SharePoint.WebPartPages.WebPart
protected override void CreateChildControls()
Microsoft.SharePoint.WebControls.RelatedTasks related = new Microsoft.SharePoint.WebControls.RelatedTasks();
… I got lazy and didn’t even bother removing the extra using statements…
Code is Well Known
Most developers and architects default to creating solutions for their problems directly in code. They put an “if…then” statement in the code and call it business logic. For example, if there is a specific property available, then the application must show an additional link. If the property shows that the user is a member of a certain group, then an additional menu may need to be displayed.
Situations like these arise every day. Creating a simple “if…then” statement is the obvious solution to the problem. But is the obvious solution always the right one?
Configuration Is Quick
Configuration, rather than a quick “if…then”, maybe the answer. Configuration is focused on creating ways to simplify individual business logic into a set of values that can be stored as configuration rather than hard coded into the logic of the program. Configuration is converting hard-coded logic into data that the program can operate on.
SharePoint’s ability to keep multiple versions of a document is a great benefit — but it can also gobble up space like Cookie Monster can eat cookies. Several clients have had issues, particularly when trying to get a migration right, where there are too many versions of a document in their database chewing up space.
Other SharePoint users face the long term maintenance nightmare of trying to control the maximum number of versions of a document when they no longer have control of their users.
Because of this, I’ve developed a command line tool (which can be easily scheduled) which will go in and “version trim” a document library. You tell it the maximum number of versions that you want to allow for a document in a SharePoint site and it will go delete all of the versions in excess of the number you specify.
The tool is web service based which means it can be run from any machine — it doesn’t have to be run from the server.
I’m finishing up some Alpha level testing this week but will be looking for beta testers early next week. Anyone interested?
If you read this blog at all you know that I rarely link to other content directly, however, I thought this was an interesting idea…
Easy Time & Billing with SharePoint, Outlook, & Excel (and VSTO too!)
These popular office system applications reduce the pain of recording and reporting your time, with very little code required.
by Ty Anderson
If anyone has noticed that the blog activity has decreased, they’re right… It’s not because I’m abandoning the concept, It’s really just a concurrence of a few things …
1) I stopped doing the TechRepublic Stategies that Scale newsletter. That was four postings a month (one a week.) I really enjoyed writing the content for the newsletter but it wasn’t aligned to the things I was doing on a day-to-day basis so I had to let it go.
2) I’m transitioning between series at Developer.com. Whenever I transition between series it disrupts the writing schedule. We should be back on track this month but it means that I didn’t have the two posts per month I normally have announcing those articles.
3) I’ve been busy trying to figure out the eCommerce portion of the software development factory that I’m doing. You’ve seen some announcements for betas… I’ve got one issue to take care of in one of the products but otherwise the feedback has been good. The net effect of which is I need to figure out how to start selling them. I’ve taken a few wrong turns (www.windowsmarketplacelabs.com) and the delay has caused me to decide that I want to build the new site on ASP.NET 2.0 which has turned out to be a giant gravity well which my time is falling into.
4) .NET 2.0 is really cool. I’ve been playing with generics and how they can take typical problems and make them easier. The obvious answer is collections. However, I’m also very interested in taking the factory pattern and making it strongly typed and generic… Unfortunately, I’ve decided that I’m starting from scratch so that means new database access code, new configuration management code, new collections code, and the new factory code … That’s meaning that it’s consuming a lot of time.
5) I can’t stop developing products. It’s sort of like an addiction. I see more needs than I can fill … I wrote a tool to manage web parts on any web part page in SharePoint (here’s a hint, almost everything is a web part page — including list pages). It will allow you to add, delete, extract, and enumerate web parts. (It’s done if anyone wants to play with it.) I’m finishing a Url Administrator that allows you to change SharePoint List Fields which are of type URL. The idea is that users sometimes use URLs in the portal that you wish they hadn’t — or you need to change. This tool will go through the entire portal and organize all of the links for you. It’s about 50% done. I also have a tool which will go through and trim the versions in document libraries — more than a few clients have accidentally turned on versions in their document libraries and now aren’t sure how to get the versions trimmed. That’s about 40% done…
6) I’ve been sleeping. I try not to but occaisionally I’ve just got to. My favorite catch phrase is “Sleep is optional.” I’m being reeducated that it isn’t.
By the way, I’m looking for a mentee, protégé, coachee, who would be willing to work for a little bit of money and some good experience. I need some help clearing some of my development tasks since I just can’t seem to get them all done. If you’re interested drop me a line.
I’ve known for quite a while that SMIGRATE backups (FPB)s were simply renamed CAB files. Today I had a collegue show me that STP files are just renamed cab files too. When you create a template — either for a list or a site the resulting STP file is just a renamed cab file with a manifest.xml file. I’m not sure what I’m going to do with this new found knowlege but it is definitely cool. (It might make it possible to apply a template to a different site definition for instance.)
I blogged earlier about using the XmlNamespaceManager to get back nodes from SharePoint XML fragments. I found a better way (with the help of some BizTalk MVPs that I got to hang out with recently). Instead of doing /wp:Fields/wp:Field or whatever nonsense that you need to do to get the XmlNamespaceManager to work use the local-name() function so … /*[local-name() = ‘Fields’]/*[local-name()=’Field’]
I’m sure someone will tell me why that isn’t very performant … but I don’t care it works, it’s clear to read, and I don’t have to go through hoops to get the XmlNamespaceManager hooked up.
This isn’t the article that I set out to write. While researching another article (coming soon) I soon realized there just isn’t a lot of good material on how to troubleshoot Web part deployment, or even precisely how Web part deployment via STSADM even works. This article is designed to explain the moving parts of the deployment process and describe what can go wrong. Hopefully, it will help a few people get their implementations up and running more smoothly.
Why Deploy with STSADM?
Before getting too deeply involved in fixing STSADM Web part deployments, it’s important to understand what STSADM is and why it’s a good platform for troubleshooting Web part deployment.
STSADM is a ‘utility knife’ type of tool that ships as a part of Windows SharePoint Services. It does a wide range of things from site creation to Web part pack installation. If you have SharePoint Services, you already have this utility; it is typically found in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60\Bin.