novolocus.com

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? Read more »

Tags: RSA, Security

Forms pages are not really that different to normal pages, but are worth a mention. These are hidden pages inside lists and libraries, and they provide the forms for creating new (and editing existing) items. They exist in a hidden _forms folder in the list:

As you can see, the forms folder for this document library contains quite a number of forms pages! So what do they look like?

Looking in SharePoint Designer at the form page, we see a web part zone containing a web part - in this case the ListFormWebPart. So why is this interesting? Well, we could put our own web part here, should we wish to. For example, you might be recording longitude and latitude on a list item - but that isn’t very intuitive. Instead, we could write a web part to display a map, and use that to update the list item.

In short, they’re not pages I’d expect to edit often - but there is quite a lot you can do with them!

| Intro | Master Pages | Normal Pages | Publishing Pages | Application Pages | Forms Pages |

Tags: List Forms

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.

| Intro | Master Pages | Normal Pages | Publishing Pages | Application Pages | Forms Pages |

Tags: Application Pages

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.
| Intro | Master Pages | Normal Pages | Publishing Pages | Application Pages | Forms Pages |

Tags: Master Pages, Page Layouts, Publishing

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

| Intro | Master Pages | Normal Pages | Publishing Pages | Application Pages | Forms Pages |

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.

| Intro | Master Pages | Normal Pages | Publishing Pages | Application Pages | Forms Pages |

Tags: Master Pages

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.

| Intro | Master Pages | Normal Pages | Publishing Pages | Application Pages | Forms Pages |

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.

Read more »

Tags: Content Rollup, Web Parts

And the final content roll-up web part I examined is Bamboo Solutions List Roll-up Web Part.

This web part is a little strange; indeed, I’m not sure how to describe it. As I understand it, basically it’s a web part to generate a data-view web part, and add it to the page. Sound strange? Well, it is a little bit. Let’s have a look:

As you can see, this is a big web part on page. It’s user interface is much more complicated than the Lightning Conductor. I couldn’t help but notice that to do filtering by metadata column values appears to require writing CAML - which really is a bit much for many users.

This web part then generates an output Dataview Web Part:

(In that example, it’s only aggregating from one list - ‘cos I forgot that gave my lists different names, and then told the view to roll-up by list name).

So, it’s advantages:

• Can consolidate across Multiple Site Collections (which isn’t possible through the Out-of-box options)
• Can consolidate a single site collection, a site and it’s subsites or a specific list.
• Can also consolidate sibling sites - which isn’t something I’ve seen elsewhere.
• Can filter by list type
• Can filter by content type or meta data fields
• Can Group results
• Has user definable sorting
• Has Pagination of results
• Fine control over caching

And it’s disadvantages:

• More complex to use
• More complex user interface
• Probably requires writing CAML
• Costs money (though I think is still a bargain compared to developer time)
• Could be a tough sell to customers (”But SharePoint already has the Content Query Web Part“)

In short: Probably the most powerful and feature rich of the web parts, but not as easy to use as some of the others. Really, more of a developer tool than a user tool.

So, on to the conclusions…

Read more »

Tags: Bamboo, Content Rollup, Web Parts

From Lightning Tools, the folks who brought us the BDC Metaman (awful name, good product) comes their ‘Lightning Conductor’ web part. Again, a slightly strange name (it isn’t copper and it doesn’t poke out from the top of a church roof). So what does it look like:

Okay, so it looks similar to the data view web part (apart from the ‘trial version’ message!), but it has the same sorts of roll up options to the Content Query web part. One of the things that impressed me about this web part was actually the configuration screens in SharePoint:

The main settings form is a well laid out, clear (if somewhat long) form. It just looks right.

The other significant administration screen with it is selection what columns you want to show, and their order, and any sorting or grouping.

Now that is much easier than displaying extra columns in the Content Query Web Part (or the Data View Web Part, come to that. Again, quite a long form, but clear, and trust me, easier than writing XSL

I did have a couple of little problems with it, though. Firstly, for some reason it didn’t seem to want to show me my Project or Project Status columns in the ‘Filters’ section, so I couldn’t restrict my view by these fields. I may have configured something wrongly that this wasn’t possible.

The other thing that struck me was that while the web part does have column headings that the user can click to sort by, there is no icon to tell them what column they’re sorting by already, or whether it is sorting ascending or descending.

So, it’s advantages:

• Good user interface. I could imagine non-technical people being able to set up their own views.
• Can consolidate across Multiple Site Collections (which isn’t possible through the Out-of-box options)
• Can consolidate a single site collection, a site and it’s subsites or a specific list.
• Can filter by list type
• Can filter by content type or meta data fields (though I had a problem with them)
• Can Group results
• Has user definable sorting (but needs a little arrow to show which column is being sorted, and in what order)
• Has Pagination of results.
• Can define view by XSL if you really want to.

It’s disadvantages:

• Costs money (though I think is still a bargain compared to developer time)
• Could be a tough sell to customers (”But SharePoint already has the Content Query Web Part“)

In short: It’s what everyone really wished that the Content Query Web Part actually was.

So, I’m quite impressed by the Lightning Conductor Web Part, but what of the other commercial option I’m reviewing - Bamboo’s List Roll-Up Web Part?

Read more »

Tags: Content Rollup, Lightning Tools, Web Parts