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.

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.

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

First off, the SDK no longer seems to include the CollectFeedback workflow, which was the only example of building a workflow for WSS and, therefore, using ASPX pages. Great, thanks for removing my one example. I eventually dug out a copy (well, actually, a colleague did) - here it is for those of you who’re curious.

I also referred to the SharePoint Team Blog’s one post about ASPX forms for workflow, which made it all look pretty simple. Really, it isn’t simple. I read that post and it sounded pretty straight forward and sensible to me, but when I tried to do it, well, I was soon lost.

Next I referred to the book Workflow in the 2007 Microsoft Office System by David Mann. It has a whole section about using ASPX forms. Unfortunately, it doesn’t really describe how to create the code for one - it pretty much says ‘download what I’ve done’, which isn’t that useful. I still don’t know how he generated this code, or understand the principle behind what he’s done.

Reverse engineering it was a bit more more interesting - though still not exactly fruitful. It turns out that his example and the CollectFeedback example both

• Create a content type for each type of Task in the workflow, which could well mean a content type for each user Task in the workflow.
• Deploy their forms into the _layouts directory, so these forms are available farm-wide.

I’m not dreadfully convinced about either of these things.

I get the first point - although having a single task content type that supports multiple forms would be useful. Often, you have the same ‘body’ of data, but need different forms; this method means that for different forms, you have to write the population of data into them uniquely. However, it’s not very intuitive.

The second point is more irritating - that the Task forms have to go into the _layouts directory. Okay, at one level, that’s fair enough; adding new .aspx files is safe enough. But how will that fit with different versions of the form? You could have different versions of the workflow available in different web apps in your farm. Can I use the site’s own master page (rather than application.master)? I can’t see that being a problem, but it’s another thing to think about. What if we wanted customisation of some of these forms, as you can do for the forms on a library? The whole customising process thing is one of the neat (and mind bending) things about SharePoint - but we’ve not got that facility for our .aspx workflow forms.

Anyway, I tried writing my own workflow; it didn’t work. Or, more accurately, the workflow’s tasks using .aspx forms didn’t work. Repeated efforts continued to fail. Frustration mounted, and then I received an email from the Ted Pattison Group about the WSS3 Workflow tools. “Interesting”, I thought, “as they must use .aspx forms”.

Well, they do. I’ve not tried them yet, but hope to do so shortly (though I’m now out of prototyping time). Consequently, I can’t say if they’re any good, but to quote a commenter on my previous post:

Best case you find it useful, worst case, it’s an example of how to write custom ASP.NET WSS workflow forms.

It looks like a pretty good framework, anyway. This does also highlight one of the pain points about workflow development in SharePoint - there is a lack of basic tooling. Given how late the Workflow Foundation settled down and how soon after SharePoint was released, I can’t really blame the development team, but it does seem sad that the development story (usually so good in Visual Studio) was so basic.

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.

So how does this work? Well, the feature.xml file refers to a feature receiver SetMaster.FeatureReceiver (catchy name, eh?) It also defines the name of the master page that we’re installing as a property:

<Properties>
<Property Key="MasterPageFile" Value="mymaster.master"/>
</Properties>

This property will be used by SetMaster.FeatureReceiver to determine the correct master page to use.

The code itself is pretty straight forward, if you look inside FeatureReceiver.cs:

public override void FeatureActivated(SPFeatureReceiverProperties properties)
{
SPWeb site = properties.Feature.Parent as SPWeb;
SPFeatureProperty masterFile = properties.Definition.Properties["MasterPageFile"];
if (masterFile != null)
{
//Save original Master Page URL
site.Properties["OriginalMasterURL"] = site.MasterUrl;
site.Properties["OriginalCustomMasterURL"] = site.CustomMasterUrl ;
site.Properties.Update();
//Update Master Pages to new URL
site.CustomMasterUrl = site.ServerRelativeUrl + “/_catalogs/masterpage/” + masterFile.Value;
site.MasterUrl = site.ServerRelativeUrl + “/_catalogs/masterpage/” + masterFile.Value;
site.Update();
}
}

Yup, all we do is get the master page name from the feature’s properties, save the URLs to the original master pages, and update the master page URLs. And yes, there are two of them, and no, I’m not entirely sure what the difference is. If anyone knows, I’d be interested.

Feature deactivation simply does the reverse.

If you dig into the other files in the manifest you’ll see that I also install an image and a CSS file, but these aren’t used in the master page we’ve installed. Unfortunately, I’ve yet to figure out how to do relative URLs that are WSS friendly, and this solution should work with WSS as is (though I’ve only tested on a MOSS system…)

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?

• 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

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.

Let’s have a look at the types of administrator again.

• Farm Admins, who we’ll assume are techies in the IT department. Their job is to keep the farm running, and that is a technical job. This level is quite distinct, and makes sense to be so.
• Site Collection Admins. Depending on what your site collection is for, these could be technical staff or advanced users. (Normally people talk about ‘business users’, but that makes it sound like having a suit give you technical ability, or that the Luddite MD isn’t part of the business). Site collection admins are in charge of the settings for the top-level site in the collection (which is usually the most high profile in the collection), and has control of Site Collection wide settings, such as search settings, usage reporting, policies, and collection-wide features. This is in addition to the usual Site administrator’s tasks, so being a site collection admin can be a pretty technical task.
• Site Administrators look after individual sites. They create lists and libraries, configure the look of pages with Web Parts, add columns of metadata to lists, set up site features, configure site navigation and set up user permissions. That’s before you look at other settings, like versioning on lists, use of content types, use of workflows, audiences. This level is supposed to be open to advanced users rather than just technical staff.

I’m not convinced this works for site admins, for several reasons:

• These roles are technical. All the concepts controlled by even just a site admin make it a technical role. You have to understand the idea behind things like Web Parts, lists and columns and views, and the slightly non-intuitive permissions structure. You have to be able to understand data and it’s relationships, and that doesn’t come naturally for everyone (thankfully, or I probably would have work).
• Advanced users don’t necessarily want to be advanced. They just want to get on with things. ‘Business’ users particularly are busy people, and don’t want to take time to learn or train - they just want to get things done.
• By reducing the IT department’s work, we’ve given advanced users more to do. It’s the classic thing in changing business processes - if one group’s job gets even slightly harder they scream foul, even if it is much better for the rest of the organisation.
• The wrong training is given… …or none is given at all. It’s become a standing joke that companies prepare their advanced users by… sending them on a SharePoint Designer course! This has nothing to do with how to set up or administer a SharePoint Site. Worse, some companies just skip the whole training of administrators (and often users) entirely. SharePoint is not as simple as a network drive, and under-trained admins and users will fail to use it correctly.
• Organisations themselves don’t won’t delegate responsibility. I guess this is the crux of things - some companies want all changes coming through an IT department. I think that there are a number of reasons:
  • IT departments have first hand experience of what their users are like and are correctly worried about giving them control. This is a pretty legitimate concern.
  • IT want to protect ‘their domain’.
  • Wanting centralised control for branding, structure, etc..
  • Departmental/branch power wrangling.
• Alternatively, the organisation has outsourced it’s IT. In this case giving the users lots of power just results in lots of expensive support calls. This factor alone has resulted in a number of pretty reduced-feature

Now, you could get around some of these issues by changing your structure, but how many organisations are going to change how their IT function works just for the sake of SharePoint? That main (and easiest) wins are, I think:

• Investing in adequate training. This is usually skipped. I’ve not yet met an organisation that planned to train it’s SharePoint users in how to use, well, SharePoint.
• Achieving buy-in from the people who’ll be doing the site administration. They might have just been given more work - you need to show them the benefits. If you don’t, they won’t do the work, and they’ll find ways of avoiding the system you’ve built.

So where does that leave us? Well, if we’re not going to change any of the parameters like training, IT structure, etc., you could well be back to having trained IT staff, in their own department, looking after SharePoint and it’s sites for the users. And actually, that’s not a bad place to be, but I do feel like it could have been so much better.

Personally, I just think that we need to be clear that SharePoint sites need to be administered by technical staff. You could still have a distributed administration model if, for example, your Finance department has their own technical administrator - but often, that isn’t the case.

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.

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.

Then in Internet Explorer you’ll have the option to open SharePoint Designer to edit the page. And that’s what it does.

It hit me last weekend (like a bolt from the blue) - you could use this to support Group By clauses on queries on a list. Yes, I know, SharePoint itself doesn’t support this functionality, but you could use the behaviour that I’d seen to support this. It’s the only explanation I’ve found that makes sense.

Now, can you turn off this behaviour, so you only get one item. That would be a lot more useful for what I was trying to do, although I now get why you might want that behaviour. Well, I don’t see a query option for it in the documentation, and cracking the service open in Lutz Reflector doesn’t show an option for it either.

I guess we’ll just have to accept the GetListItems command in the Web service API supporting Group By functionality, while SharePoint’s user interface itself does not. It’s a bit weird though that there isn’t an option I can find to turn it off though, and the Object Model behaves quite differently - it only returns one ListItem, and is unaffected by the multi-select lookup.

<%= Request.QueryString.ToString() %>

I got the error “code blocks are not allowed in this file”. This makes sense, as otherwise anyone with SharePoint Designer could put arbitrary code into a page and get it to run. Clearly, as this would let business users enter code, this would not be very secure.

Now, you can turn off this security restriction using Page Parser Paths, but this reduces the security of the system - again, anyone with SharePoint Designer could put code in without review/authorisation. Again, less than ideal.

Well, one of the things I learnt last week was that uncustomised pages (or ‘ghosted pages‘ for the oldies) will run inline code. Fantastic! After all, we’re going to want to package up our code for deployment from Development to Testing and Production systems, right? (Well, you should be, dammit!)

For those of you who don’t know, uncustomised pages are ones that are stored on the server’s hard drive, rather than in the database. To get onto the hard drive, someone has to install them, which means that someone has to review and approve the code. With SharePoint designer, this isn’t the case, and SharePoint Designer can only create pages that are Customized (or Ghosted), and so exist only in the database.

So overall, the process would probably become:

1. On a development system use PageParserPaths to enable inline code. As this is a dev system, security is less of an issue, and business users won’t be making changes.
2. Develop your pages that use inline code. You can do this in SharePoint Designer.
3. When the pages are complete, copy them out and package into a feature. Make sure that your page that you’ve written in installed Ghosted - still the terminology they use in features.
4. Install and activate the feature. As your page is now uncustomised (or ‘ghosted’), it will now run inline code without PageParserPaths being configured.

That’s a pretty tidy developer story!

Anyway, the training was pretty good. I found that I got a lot more from the start of the course (which focussed on WSS3) than the later bit which focussed more on MOSS; I’ve been surprised a couple of times by just how much there is and how much you can do with WSS (and it is practically free!) The MOSS stuff is a bit more familiar - but it’s the MOSS stuff that I’ve been working with mostly.

The course started with a brief introduction/history of SharePoint, looked at what type of developer and background you might have coming to SharePoint, and then into architecture. The rest of the modules were then pretty much what you’d expect:

• Development vs Customisation, how Features work
• SharePoint Architecture and how pages work
• Pages and Site Branding
• Developing Web Parts
• Lists and Content Types
• InfoPath 2007 and Forms Services
• SharePoint Workflows
• Extending MOSS Portals and Search
• Web Content Management
• Business Data Catalog
• Excel Services and Reports Center
• Application Security

The lab exercises were good, and pretty realistic. The workflow one seemed a bit light, and none went into that much detail, but then again, some of these areas could be a week’s training in their own right (and I notice that Ted Pattison Group do offer a 4 day workflow course…). It was all quite pragmatic; I liked it.

The other things I took away were a bit less directly about the course. Firstly, there is value in having a course run over its originally intended time. The last two SharePoint courses I’ve been on were two weeks reduced to one, and 5 days reduced to 2. The first had me studying from 8am to 11pm most days, and the second just didn’t cover as much as it could have; it’s quality was compromised. Getting the instructor to talk twice as quickly does not make me learn twice as much. This course benefitted from a reasonable pace and scope.

The second thing I took away was the quality of the trainer. For development training, the trainer has to be another developer, even if it isn’t full time. Ruth, who took this course, was very good; she’d clearly been at the sharp end of SharePoint development and felt the pain, and was willing to say ‘I don’t know’, which anyone working with SharePoint will have to say sometime or another. Anyway, she kept the course filled with useful tips and clarifications; I hope I supplied some back myself. Previously some of my colleagues have had trainers who are trainers, not devs - this was not as good

I do think that I would have taken more away from this course if I’d not already worked so extensively with SharePoint - it’s perhaps a better course for folks who’re relatively new to SharePoint development. It was also fairly clear that being a strong ASP.NET developer would really help too; I’ve said it before, but I think good ASP.NET 2.0 skills are an essential prerequisite to SharePoint development.

So I opened up my search page in SharePoint Designer. This always looks a bit cluttered, but I went to my Core Search Results Web Part to modify it’s ShowActionLinks property.

I’ve scribbled on this to highlight the obvious web parts on the page. The Core Results web part is highlighted in cyan. Anyway, if you look at the code in the top of the screenshot you can see that the ShowActionLinks setting is already False. Eh?

Obviously, I decided to set this ShowActionLinks setting to true to see what happened:

Now there are two action links shown. (Please note, I made some other changes while figuring this out, which is why the results themselves look a bit different). Okay, so clearly, there must be another web part. Rather than look at the pretty pictures in SharePoint Designer, I looked at the rather more useful code and found:

That’s right, there is a second Core Results web part, which is nearly invisible in the Design view of SharePoint Designer. This web part’s XSL doesn’t actually process the Results nodes of the search results - so it doesn’t show any results (which kind of belies it’s name as the ‘Core Results’ web part). Instead, it just shows the action links.

Frustratingly, the second Core Results web part is very obvious if you edit the page in the browser:

I deleted that web part from my page, and the action links vanished. I guess the question that this leaves is why are the action links not in their own web part? After all, it’s not called the ‘Core Results and Action Links’ web part is it? It rather appears that they would nicely sit as their own web part.

The important thing to remember is that a simple search is just a URL, and specifies the search term and scope in the k and s parameters respectively. E.g. This search url:

http://deltamoss01/searchcenter/Pages/Results.aspx?k=Badgers&s=All%20Sites

would run a search for badgers in the All Sites scope.

It is worth noting, however, that this is saving the search, not a set of search results. As the index is updated, the results on this page may vary. Also, advanced searches don’t pass their parameters as GET parameters (i.e. within the URL), so you can’t save these the same way. I’ve not yet found a way to save them.

As another note, the standard Search results page shows the ‘Alert Me’ link:

This lets you set up email alerts about new items that match a search:

Really, that’s pretty neat.

Anyway, assuming that you’re not going to use Alerts, then you’re looking at storing URLs. You could use a List, such as a links list, but my colleague made the interesting suggestion of using the ‘My Links’ functionality of an account:

And then you can add it to your My Links list:

Which are shown on your My Links menu:

So there we’ve got one way of saving a search in SharePoint. In reality, there are a lot of alternative - Links lists being an obvious choice, but there are things like summary web parts too. Really, it’s anywhere you can store a URL.

When I perform a standard search in SharePoint, it shows me what I’ve been searching for:

That’s good - it’s useful to know what you’ve searched for. If I then click on ‘Advanced’ the advanced search page opens showing my search term, and a number of other fields I can fill in for a more specific search.

If I then run that search, though, I get the following results page:

Okay, now that is a little odd looking. There is no search term in the search input box. This is perhaps not surprising - the advanced search screen can express more complex queries than the text input box of the simple search control. However, there is nothing to tell you what the results are of. You have no idea what the search was that gave these results!

Worse happens if you try to go back to your advanced search page. Unless you use the browser’s Back button, you will lose your current query. There is no obvious way of ‘refining’ an advanced query.

It looks like this is happening because the simple Search box passes it’s parameters in the URL as GET parameters, but the Advance Search page uses a postback-then-forward approach.

Is it too much to ask for to have a web part that describes what the conditions of an advanced search are, and to store that query to pass back to the Advanced Search page, should the user wish to refine their query.