novolocus.com

An interesting question from one of my colleagues:

Can you sync the Pages list with an Outlook 2007 folder and still be able to read the HTML without the MOSS CSS and XSLT stuff?

Well, my gut feel was no, but I thought I’d take a look.

I found that the Connect to Outlook option was available on the Pages library settings, so I thought I’d give it a try.

As we can see, we do have the Pages library synched, and you can see the pages within, but Outlook doesn’t know how to display them. I’m not surprised to be honest; I suspect that the default.aspx item actually just contains the data for the page - but isn’t yet rendered by the page layout or page. Still, one way to find out - open it and take a look:

Yup, there you go - the XML of the page ListItem, and not a nice, rendered page with all the layout, master page, styles and stuff. Not really surprising, to be honest, but it would be nice if it did. I can’t think of how it might do that though - clearly the whole browser page would need to be rendered. An alternative would be to generate your pages via the Document Conversion Service, and to synch with the source documents themselves, rather than the pages.

So, recently I’ve been looking at .aspx forms in SharePoint workflow. It turned out to be a very hard experience, although there is a project on codeplex that might make life easier. I’d like to try it, and if it works as billed, I’d like to buy it’s author a pint.

Anyway, this set me thinking - why are .ASPX forms not the default way of creating forms in SharePoint workflows?

Infopath has it’s uses. In the last few months I’ve played with it a few times and found it fairly useful for what it was originally designed for - providing forms for people to fill in. It has some nice features, which I must post my thoughts about sometime. And, for what is quite a complex task, it’s relatively simple to use (relative to development, I mean, not relative to using, say, MS Word).

What it’s not designed for is providing workflow forms for SharePoint, and that’s part of the reason this is such an arcane process.

Worse, one of InfoPath’s selling points is that ‘power users’ can create and use forms without needing developer input. However, creating SharePoint workflows through Visual Studio is clearly a developer activity - no non-techy is going to manage it. So what are we using InfoPath forms for, rather than ASPX forms which we can also write in Visual Studio?

Finally, InfoPath forms don’t work with WSS3. With the lack of documentation and tooling for using ASPX forms, this effectively cripples writing custom workflows for WSS3. The cynical amongst us might suggest that this is a way of trying to force companies to cough up for MOSS (which contains InfoPath form server), but to be honest, I think it’s just an oversight.

Curiously, InfoPath forms seem to work much better in K2’s BlackPoint than with SharePoint’s workflows. Building InfoPath form tasks in K2 was simple compared, and worked with little effort. Unfortunately, the simplicity comes with a price tag, and as SharePoint already ‘does workflow’, few companies are that keen to pay for it.

So please, please, for Office 14 make ASPX task pages the default workflow building scenario, and make InfoPath the ‘alternative’. That’s in addition to making InfoPath forms actually work properly in workflows… …and maybe take some lessons from K2.

So I was playing with SharePoint search a while back, and I was wanting to display some results differently based upon what type of item the result was for.

It turns out that there is a node in the results xml file that shows this - ContentClass :

As you can see, the first highlighted result is STS_ListItem_DocumentLibrary. Pretty clear what that is. Not all results actually have a content class - the second highlighted result is from a document on a file share, and it doesn’t have a ContentClass.

So what content classes are there? Well, Dan Attis has a good list, along with a caveat about Welcome pages in the results. There is a similar list here. (Nobody mentions not having a ContentClass though). But unfortunately, I don’t know how to add new content classes

Well, I said I’d blog about how well I managed with using SharePoint Workflows with ASPX forms. The short answer - badly. Read more »

Team sites don’t have the Publishing features of MOSS enabled by default, and for WSS systems, well, you don’t have them to enable. Consequently, if you deploy a master page as a feature, you’ll have a bit of fun setting it as the master page.

You can do this though SharePoint Designer, but it’s possible you don’t want your Site owners to have SharePoint Designer, or maybe you just don’t want the hassle of the second step when you provide the master page for a site. Instead, it is possible to set the Master Page through code, and to fire this using a Feature Receiver. This features shows just that - setting the master page through code. Note that to install it, you might well need to make some changes to install.bat. Read more »

So, I was really stuck with a Master Page that I’ve been building as a demo. This master page was for use on a site without the publishing features, such as a Team Site.

I wanted to provide a separate CSS file and an image for with this example. However, I hit a snag - how to get relative URLs to the CSS file and image that I was putting into the site?

For Publishing sites, this isn’t normally a problem - you put things such as the master page or images or CSS near the root, and then reference them from the root of the site collection. But from the subsite I was using, this proved hard.

Well, in the end I turned up this post from Ben Robb about using $SPUrl. It turns out that this works nicely for images, and for links to other content, such as CSS files:
<link id="css1" runat="server" rel="stylesheet" type="text/css" href="<% $SPUrl:~site/_catalogs/styles/mystyles.css%>" />
or
<img id="img1" src="<% $SPUrl:~site/images/badger.png%>" />

Unfortunately, it relies on the Microsoft.SharePoint.Publishing namespace, which means that this solution isn’t WSS friendly; certainly I couldn’t get it working. Or rather, maybe it isn’t - perhaps the Microsoft.SharePoint.Publishing namespace is available in WSS3, even if the publishing features themselves aren’t. Does anybody know about that?

So I’ve got a big project that is, apparently, to be based around workflow coming up. I’m a little scared of this, to be honest. I’ve noticed a few things:

• The most viewed item on my blog is currently ‘Blood, Sweat, and Windows Workflow in SharePoint‘.
• There are so many questions on the SharePoint UK user group about workflow.
• There are so many questions on the Microsoft forums.

So, anyway, my boss was wise enough to give us some time to refresh ourselves about SharePoint workflow, and to try out some things we didn’t do before (like using ASPX forms). It seems to me that some things have moved on - the projects in Visual Studio have got better (although I’m not sure I like the ‘deploy’ thing in the Visual Studio 2008 templates - what if I have other steps to perform? Is the deploy the same as what I would do if I was deploying a new WSP? It doesn’t seem so - it appears to be too fast!)

However, some things still really don’t work:

• We can still see odd (and incorrect) behaviour for infopath forms that use Repeating groups. One of my colleague gave this a look - it still doesn’t work.
• Still no proper tracking and auditing - I guess we’ll have to build it into the workflow ourselves.
• Still a general lack of documentation about workflow, and this is 18 months after release.

Anyway, I’m off to try using ASPX forms - I remember reading that that was possible. Wish me luck (for the ASPX and for the project). I’ll blog about how it goes

I like the Admin model in SharePoint. We have a structure of Farm administrators, who keep the system running, backed up and reliable. Then we’ve got Site Collection admins, and Site Admins.

Delegation of administrative responsibility is, in my eyes, a Good Thing. IT departments are busy, and have to prioritise work, which can make them seem unresponsive to an individual user’s/team’s needs. By giving the users the right to administer their team’s/department/group’s site, they can get on with getting things done without having to bug IT all the time - which ultimately annoys both parties.

However, I’m not convinced it is working. Read more »

Edit: As Steven Van de Craen points out, you can use the Properties collection on the Root folder for the List. Neat, didn’t think of that.

I like property bags in things. Sure, they’re open to abuse, but they give an easy way of storing a little extra data, and as a developer, I find that very useful.

For those of you who are wondering what a property bag is, well, it’s a collection on a object where a programmer can just store stuff. E.g.

SPWeb site = properties.Feature.Parent as SPWeb;
site.Properties["Kumquat"] = “True”;

Now, clearly the SPWeb object in SharePoint’s API doesn’t have a property called Kumquat; we’re defining a new one, and storing a string. In fact, string objects is all you can store.

Anyway, SPListItems and SPWeb both have property bags, but SPList and SPSite do not. Which is a little annoying, as I want to store some data at the list level, dammit. And I hadn’t realised this ommission until now…

Thoughts on Steven’s point - it’s a good one, and using the root folder would work. Naturally, this means that you’re storing the properties in the SPFolder object, but each list should have one of those, I think. It’s a bit of a pain as, if you’re using the Web Services then I’m sure that  getting that root folder will take another call - but as I’ve not validated that the properties are available via the web services, then that might be a moot point anyway.

This was such a good question, I thought I’d reply in a post about it:

I am trying to limit the depth of the breadcrumbs. I have a sub sub sub subsite that I want breadcrumbs to show from that site and down one more level. I can make the breadcrumbs invisible using SPD but I wonder if I can make them limited … like we could in WSS 2. - Jo Arnspiger

Well, there are a couple of ways that spring to mind (there are many approaches, but these are probably the best two) - one that uses SharePoint Designer, and one that uses SharePoint’s own navigation configuration.

First off, let’s look at the SharePoint Designer route. If you go to your master page or page layout, you’ll see an ASP control called the SiteMapPath control. It has a property called ParentLevelsDisplayed.

Set that to a number, and that should be the maximum number of levels shown. If you set it to -1, it will show however many levels there are, which is it’s default. (I’ve not tried it, but I’m pretty sure that’s the case). That’s probably what you want, but there is a problem - it’s not just your master page which defines the SiteMapPath control. There is one on most of the Publishing Page layouts that come out of the box too. Still, if you’re happy taking a little time to change all of them, then that’s probably fine.

The other problem is a little more fundamental - this setting will apply across your entire site collection. Well, okay, maybe not, but it’ll apply for all pages using that master page or page layouts…

Alternatively, you could change the Site’s navigation settings to get what you want. At the ‘sub sub sub subsite‘ you could change the site’s navigation setting to not inherit it’s top navigation settings from the parent site. This will add a level to the ‘Global Navigation’ breadcrumb, but also make all URLs below the ‘sub sub sub subsite‘ start at that level. See my previous article for an explanation.

The down side about this approach, though, is that it means all of your top navigation tabs will change - you really are breaking with the ‘navigation context’ of the parent site. (That’s my term - I didn’t know what else to call it.) There is an example of this on the article linked to above.

A final note, these approaches do have two slightly different results - the first route is a ‘only show the last X items’, while the second is ‘chop all breadcrumbs below this site to start here’.

Anyway Jo, I hope that one of those is suitable.