Highlighting tabs in the top navigation

2009-04-072014-11-30 Andy BurnsNavigation, SP2007 Admin, SP2007 ArchitectureLeave a comment

We’ve got a customer who’s top navigation tabs aren’t being used as links to content in SharePoint. Instead, these tabs take users to other parts of their system, which is maybe fair enough given that the left navigation also gives them the same sort of access; indeed this duplication of navigation is often a source of consternation with clients.

Anyway, they’ve now added site that they do want linked from the top navigation bar. Therefore, if you click on this tab, they want it to appear highlighted – and it’s the only tab that would.

The site in question isn’t a subsite of the root site of the site collection, so I must confess, I didn’t think you could do this. They emailed and asked, though, and I suggested that the full URL that they were using (e.g. http://sharepoint/somesite/tabsite) wasn’t a good idea – as if they extend their web app for an extranet that link won’t work. As it transpired though, they’d thought to try a relative URL (e.g. /somesite/tabsite) and that worked nicely!

I had to check:

showing:

There we go, a site 2 levels down, highlighted in the top nav correctly!

I suppose it makes sense that the relative URL might work – but I’d sort of assumed that the manual links wouldn’t undergo the same checks as the ‘show subsites’ links would.

Plan Your Publishing Pages

2009-03-022014-11-30 Andy BurnsPage Layouts, Publishing, SP2007 Admin, SP2007 Architecture, SP2007 Branding, Web Content ManagementLeave a comment

I was reading Andrew Connell’s book ‘SharePoint 2007 Web Content Management‘ and it made something crystallize for me. I’ve been pondering this for about 8 months or so, but I believe that several of our customers are using the Publishing features of MOSS incorrectly, and that simply basing sites on out-of-box Collaboration and Publishing site templates is a mistake.

(Well, at least without additional planning) Continue reading “Plan Your Publishing Pages” →

RSA SecurID and SharePoint

2008-09-162014-11-30 Andy BurnsRSA, Security, SP2007 Architecture, SP2007 Development2 Comments

I’d an interesting question from a customer the other day – they wanted Forms Authentication on extranet access to SharePoint, but using two factor authentication. The product mentioned was RSA SecurID, and this means that to authenticate yourself you need:

Your Username
A hardware device that shows a pseudo-randomly generated PIN number which changes every minute or so.

‘Cos the PIN is a pseudo-random sequence, if the token and a server are in sync, you can validate that someone has read that token inside the last minute. It’s an expensive technology – but neat!

The idea is the same as, say, a credit card. More than just saying who I am and that I have some piece of knowledge (e.g. my PIN number), I also have to have a physical object which is hard to duplicate (my credit card). This should make my identity more certain.

Anyway, how does this fit with SharePoint? Continue reading “RSA SecurID and SharePoint” →

Pages in SharePoint V – Application Pages

2008-08-182014-12-01 Andy BurnsApplication Pages, SP2007 Admin, SP2007 Architecture, SP2007 Development1 Comment

Application pages are a pain. They exist inside the _layouts directory, and are common to all the files across the farm. This makes them difficult to change, as such changes happen thoughout the system, not just one site or site collection. They’ve also got their own master page – and it’s difficult to change, which often you want to when branding a system. Essentially, you should try not to need a new master page (application pages can be modified by Themes, so that’s one way of branding them).

So what is an application page? Well, it’s a standard ASPX page. They’re usually for site administration type tasks, though there are a number of pages that users are likely to see regularly that are also application pages – such as file upload, the recycle bin and the “View all a site contents” page. Therefore, there is a problem – you can brand up your SharePoint Site, but if a user tries to upload a file they’ll drop out of that branded experience. For example, this example shows a SharePoint Site using a custom Master page (background window), but if you try to upload a document to that site you’ll see a standard upload page (foreground window). If you look in the URL for the upload page, you’ll notice it’s in the _layouts directory:

Like I say, you can change the style of this window through themes, but really that means just changing the colours – changing the structure of the page is much, much harder. Below is an example of changing the Site’s appearance through themes – you can see that this applies to the upload page too.

You shouldn’t change application pages themselves, as they are core to SharePoint and you won’t be supported by Microsoft – but you can add your own, should you want to present your own farm-wide administration pages.

Pages in SharePoint IV – Publishing Pages

2008-08-152014-12-01 Andy BurnsMaster Pages, Page Layouts, Publishing, SP2007 Admin, SP2007 Architecture, SP2007 Development3 Comments

Publishing pages are specific to MOSS, as they require the publishing features! They’re not in WSS3! A good example of a publishing page is the default.aspx of a Collaboration site – that’s right, although the default page has the same name as for a team site, it is quite different:

Looks pretty much the same though, eh? That’s because it uses the same master page, but we’ll come to that in a bit.

These pages are are stored in a ‘Pages’ library (you can see this highlighted in the URL). They aren’t really like documents though; they’re much more like list items. Basically, these pages are collections of metadata columns. Different pages have different content types, such as the ‘Press Releases’ page type of the Publishing Portal site template. The other pages types that come out of the box are the ‘Article’ and ‘Welcome’ page types of a collaboration site.

These content types have different columns of data. For example, you might have a type of page for ‘Vacancies’, and that might have columns for position, salary, etc.. You might also have a type of page for ‘Products’ which might have columns for part number, cost, stock, etc..

Okay, so I’ve said that these pages are more like collections of metadata – how does this become a web page that you can see and read? Well, each page type has one or more page layouts. Lets have a look at one in SharePoint Designer:

These are kind of like master pages – they define the layout of our metadata columns in an aspx page. In the one shown above there are only 2 metadata columns, which I’ve highlighted – Page Image and Page Content.

Okay, but what about the master page stuff? Well, out page layout the content controls to go into our master page. Confused? It is confusing, so here is a diagram to show this:

Here you can see the page metadata being put into the page layout, which in turn puts content into the master page, which finally generates the output that gets sent to the user.

One advantage of this approach is that you can change between different page layouts for a given publishing page type – for example, you might have ‘Product page with image on left’ and ‘Product page with image on right’ layouts. Changing the page layout does not require editing any of the content.

Pages in SharePoint III – ‘Normal’ Pages

2008-08-142014-12-01 Andy BurnsSP2007 Admin, SP2007 Architecture, SP2007 Development1 Comment

‘Normal’ pages are just ASPX pages. They usually (but don’t have to) use a master page, and we’ll consider them in that way. First let’s look at a good example – the Default.aspx of a Team Site.

Looking at this in SharePoint Designer we see the following:

On the left we see that our page just exists underneath our Team site – it isn’t in a Library or anything. On the right we see SharePoint Designer shows us the master page that the page uses at the top of the page, and what the page would look like. You can see the PlaceHolderMain placeholder is highlighted, and unlike the master page, this one has content. I’ve also circled where the PlaceHolderTitleBreadcrumb placeholder is, and this is now empty. So where did this content come from?

If an aspx page uses a master page then it says so in it’s code, and it defines a number of content controls. These content controls match up with the placeholder’s in the master page, and define the content to put in there. If we look at the code (don’t panic!):

Here we see the content being defined for the our PlaceHolderTitleBreadcrumb (the new content is ‘nothing’, and so our breadcrumb is effectively being erased), and our PlaceHolderMain (which contains lots of code for 2 web-part zones, etc.).

So, just to reiterate, a typical page in SharePoint defines content that is put into a master page. The process is something like this:

Pages in SharePoint II – Master Pages

2008-08-132014-12-01 Andy BurnsMaster Pages, SP2007 Admin, SP2007 Architecture, SP2007 Development2 Comments

Master Pages are actually an ASP.NET 2.0 technology. They allow you to create a page with a number of ‘placeholders’ (there are a lot of these). Below is a view of the default.master page for a team site.

You can see that the master page already has controls for navigation, search, site actions, etc. built in. I’ve also selected one of the placeholders – PlaceHolderTitleBreadcrumb. These placeholders give locations on the page for other .aspx pages to put content into. For example, the default.aspx page for a Team site puts content into the PlaceHolderMain and PlaceHolderTitleBreadcrumb placeholders, amongst others – we’ll look at this below. Now, the observant of you will notice that the PlaceHolderTitleBreadcrumb placeholder shown above already has content – the breadcrumb to the page’s location. A placeholder can define default content, but the page that then uses the master page can override it, and put it’s own content in. For example, in our master page the PlaceholderMain has no content, but this will almost always be overridden.

Master pages normally exist in a Master Page gallery, which is hidden from normal users. You might have many master pages, though you normally only use 1 on each site. By changing the master page you’re using you can make major changes to the layout, look and format of your site.

Pages in SharePoint – Introduction

2008-08-122014-12-01 Andy BurnsSP2007 Admin, SP2007 Architecture, SP2007 DevelopmentLeave a comment

Right, I’ve had to explain this to various co-workers, and it is fundamental to how SharePoint works, so here we go with how pages work in SharePoint.

Let’s start with the hardest part. There are many types of page in SharePoint, and they’re all referred to as pages. You’ve got:

Normal pages. These just live in a site; they don’t exist in a Library, they are specific to that site, and they don’t require the publishing features. An example is the Default.aspx of a Team Site (though NOT of a collaboration or publishing site – see below).
Publishing pages. These are a special type of page. They require the Publishing Features of MOSS, and so aren’t in WSS. Publishing pages have a content type, and always exist in the Pages library of a site.
Application pages. These are administrative style pages, and exist in the _layouts directory. They are common to all sites/site collections across the entire farm. Consequently, these files should not be changed (though you can add new ones if you want)
Forms pages. These are a bit different – they’re the pages for viewing and manipulating items in a list. They exist in the hidden Forms folder in the list itself.
Master pages. Not really pages, but more like a framework that other pages can put their content into. They do have default content though, and this is often used for things like navigation, the Site Actions menu, etc..

There are other complexities, but this is enough to be getting on with for now. Let’s look at each of these page types, starting with Master pages.

Content Roll-up options – Conclusions

2008-07-242014-11-30 Andy BurnsContent Rollup, SP2007 Architecture, SP2007 Development, Web Parts8 Comments

So, what what content roll-up web part to choose? Well, typically (for SharePoint) it depends.

Bamboo’s List Roll-up Web Part is the most feature rich, but a bit tricky – certainly it’s a bit too complex if you’re wanting to allow users to set up their own roll-up. The use of CAML is also a big no-no for allowing basic users to set up their own. It’s a shame; it really is let down by this complexity, although it’s still simpler than using SharePoint Designer.

Using the Dataview Web Part directly has the same problem as Bamboo’s List Roll-up – complexity. It also requires SharePoint Designer. It’s harder to generate the Data View Web Part, but to be honest (given that you can do the same things as Bamboo’s List Roll-up web part) I suspect that most organisations would be fairly willing to live with that.

For me, it’s main problem is that it doesn’t pick up new lists automatically; you have to modify the data view web part to add the new lists. For that reason, I think you can only use this approach when you have a fixed set of lists to aggregate over.

The Content Query Web Part is pretty good, and there is a reason that it’s so often discussed in SharePoint Solutions. The web part itself is fairly straight forward to use – but using custom metadata in the display is a bit too complicated. Again, I think this solution is out of the range of the ability of typical users. I don’t like the lack of pagination options, either.

Lightning Conductor is the only one of the web parts that struck me as being simple enough that a non-technical person would be able to set up and use for content roll-up. It had many of the more complex features that we’ve seen (e.g. using XSL for formatting the results), but you didn’t have to use them, and the user interface exposes things that seem missing from the CQWP – like the ability to select the fields you want in the display! I’ve got to say, this is my favourite of the solutions I looked at.

So which one should you use? Well, as I said, it depends. The main factors involved seem to be:

Are you wanting to aggregate across site collections?
Are the source lists fixed, or will they be changing?
Will the roll up be configured by technical or non-technical staff?

I guess you weigh those up and take your choice.

Edit: One questions I was asked was if it’d be difficult to write your own. Well, there’s no reason why you couldn’t; with the SPSiteDataQuery it wouldn’t even be hard. Programming around the configuration would take longer, and as we’ve seen, this can make a big difference to the usability of your solution. What I would observe is that both the 3rd party solutions were pretty cheap; it’d be diffult to write your own for as small a cost.

Edit 2: A good post on when to use the CQWP vs the Lightning Conductor Web Part from Lightning tools…

Continue reading “Content Roll-up options – Conclusions” →

Andy Burns' Blog

Whatever I'm working on

SP2007 Architecture