• Open Control Panel > Add and Remove Programs
• Find your Office installation. Click Change.
  
  
• Choose that you want to Add or Remove Features and click Next
  
• Select that you want to Choose advanced customization of application. Click Next
  
• Expand the Microsoft Office Outlook branch and look at the item .NET Programmability Support. A little hard disk icon means it’s installed, a red cross means it isn’t, and a hard disk with a ‘1’ means that it’s not installed, but will try to install it the first time it’s used. It should look something like this (although the yellowness is to highlight the setting):
  
• Click to exit without installing. To install, you’ll need the appropriate disc.

I thought that this was quite nice. I wondered if I could make something similar to this using the Summary Links web part - curiously, it’s something I’ve never really used, and I though I remembered seeing that it could show images too. So, I set up some examples…

First off, I looked at the different styles of links you could put in. Interestingly, you can mix these in the one Summary Links Web part:

Quite a lot of styles! The image I used for m links is the one with orange text saying ‘This is an image’ - original, huh? (Note: the second and third links up from the bottom are just Image links. On is clickable and the other isn’t… ) None of these are really styled the way I’d want though.

Next, I took a look at the Group Header Styles:

Again, nothing that would obviously do what I wanted - no images for a start. For completeness, I should say that these settings were configured via the ‘Configure Styles and Layouts’ option, which opens this dialog:

So, what other options? Well, I wondered if I might be able to move things around a bit and use the normal ’styles’ of link through applying a bit of CSS. So, I opened the IE Developers toolbar and started taking a look. I found that I could see the different DIV tags for each link item, and they had different styles applied to them:

Great! What structure is within those items though:

Damn, they’re all different. Well, that idea bites the dust. I guess that I’ll have to look at a custom web part.

As a side note, I also discovered that you could have multiple columns. You can’t have a single Group heading with multiple columns, but you can have Group headings in columns with a single column of links underneath, like so:

Basically, this is a Lookup column where the List that it is looking up onto is the same as the list where the lookup column is in use. In our case we had a list called ‘Issues’, and the lookup was a multi-choice look-up called ‘Related Issues’. It would let a user select things from the Issues list. All in all, a perfectly sensible use of a multiple lookup, and one I’d not thought of!

However, this in itself wouldn’t cause my plug-in to suffer an error. The problem was with the data I was getting back from the Web Services I’m using. I use the List Webservice’s GetListContentType method to get information about the Content Type, and I then read the information about the fields. Lookup fields normally come through with an attribute List ; this is the list that’s being looked up onto, and normally it is a GUID. However, for self-referencing lookup instead of a GUID, you get a string ‘Self’‘. Okay, I can’t argue that it’s wrong, but it’s a smidgen annoying that it is inconsistent. Couldn’t it just give me the GUID and let me figure out if that’s the same list? Or use another attribute to denote that it’s a self-reference?

I don’t get why this was built that way.

From the article:

Versions of the .NET Framework

There are currently three released versions of the .NET Framework. The releases have the following version information.

Note The Microsoft .NET Framework 1.1 is included with the 32-bit version of Microsoft Windows Server 2003.

Note This information should be used as a general guide for determining which versions of the .NET Framework are installed on a computer. Also note that files that have a later version listed may be files that were shipped as part of a hotfix or a hotfix rollup package. The hotfix .NET Framework file versions are outside the scope of this article.

Determine which versions of the .NET Framework are installed on a computer

The easiest way to determine which versions of the .NET Framework are installed on a computer is to locate the %systemroot%\Microsoft.NET\Framework folder. You can paste the listed address for the Framework folder into a Windows Explorer address bar to navigate to the Framework folder. The three released versions of the .NET Framework are contained in the following folders:

Note If you see other directories that have a vN.N.NXXXX format that are not listed in this article, the versions may be beta versions or pre-released versions of the .NET Framework. Those versions are outside the scope of this article.

To determine which versions of the .NET Framework are installed on a computer, follow these steps:

1. Writing content directly using the Content Editor control (the RichHTMLField control)
2. Writing content in Word 2007 and using the Document Conversion service
3. Writing content in Word 2007 and cutting and pasting(!)

I decided to test and compare these techniques. For options 2. and 3. I used this document:

Let’s look at the results of this and the code that is behind each resulting page…

Authoring Directly with the Content Editor

Obviously, the styles available in my Content Editor control didn’t (out of the box) match those I had available in my Word 2007 document. However, you can configure these - I didn’t bother. Thus, the output for this test was similar but not the same as the test document:

The code looks like this.

So, what does this code show us? Well, we can see that our Content Editor Control’s styles appear in the code as styles - e.g. ms-rteCustom-ArticleHeadLine - and that other changes to the text appear as inline code - e.g. <font color=”#ff0000″>.

These inline styles are a problem. You can use a stylesheet to control the look of the styles available in the Content Editor control, but that’s not true for style code that appears inline. Fortunately, you can prevent other styling options in the Content Editor control. (A lot of information in that article!)

So, we can lock down the styles to prevent users from causing the creation of inline style code, and we can give them a set of styles to use. Thus, we can enforce the use of a consistent set of styles, which is always great if you might want to change the styles you’re using throughout your site.

The down side of this approach is, well, it’s not a familiar authoring environment. A lot of content authors won’t want to learn a new system.

Author in Word and use the Document Conversion Service

Microsoft Content Management Server 2002 (MCMS) had an Authoring Connector - a plug-in that let you write your document in Word and convert it to a document. SharePoint 2007 has similar functionality in a feature called either ‘Rich Client Authoring’ or ‘Smart Client Authoring’.

Essentially, this lets you convert certain files (.docx, xml, infopath forms) to a publishing Page. There are some limitations to this, such as what happens to metadata, and what happens to embedded content. This last one is particularly relevant as many Word documents do contain images as diagrams, etc.. We’ll come back to this later.

Anyway, what is the output of the document conversion service when run on our test file?

The code looks like this.

This code contains a series of Paragraph and Span tags for various styles - e.g. Normal-P and Normal-H. The Document conversion service puts the definitions of these styles from the document into another field in the head of the converted HTML page, although defaults are also defined by a standard stylesheet called RCA.css. (Note that in the screenshot above I’ve told the conversion service not to save the style definitions from the document - though it does retain where in the document the styles are used.)

Again, we also have inline styles from formatting text in Word - but we can restrict users to only using the predefined styles. These predefined styles are translated to CSS classes. So again, we can force the styles to conform to a particular set, and then define these styles in a CSS stylesheet.

I guess the other point of note is that the actual structure of the HTML involved is quite different to what you’d create by authoring through the Content Editor control.

Author in Word then Cut and Paste into the Content Editor Control

This option took me by surprise a bit, but it makes sense - the authoring is in a familiar environment, and, well, cut and paste isn’t scary. I cut and pasted the content of my test document into a new page…

This is what the code looks like.

Again, our custom style in our .docx file has been translated to a CSS class. The Heading 1 style has just been translated to a <h1> tag. And the normal paragraphs are <p> tags with a style of MsoNormal.

Again, we’ve got our inline style, but again, we can prevent this by restricting the word document template to predefined styles.

And again, the structure of the HTML is not the same as either of the two previous methods. My own feeling is that this code is not as neat; I don’t like the way that the Heading 1 and Heading 1 Red styles are translated differently - one into a paragraph, the other into an <h1> tag. But you could define CSS to style this content too.

Regarding Images

One issue is images. The Document Conversion Service (bizarrely) doesn’t handle embedded images. You can work around that though, by linking images into the Word document rather than embedding - just don’t try and work with them offline!

Similarly, cutting and pasting looses any embedded images (though SharePoint is kind enough to warn you - kudos). And I’ve not been able to cut and paste with Linked images rather than embedded ones, so in that regard this method is actually a little worse.

I’ve gotta say, I’d love the time to have a go at making the document conversion service also store embedded images into a library and map images in the document to those images. Perhaps that’d make a good codeplex project?

Final Thoughts

So, online authoring through the Web Browser is the simplest option and doesn’t have any pitfalls - but it is most likely to scare/annoy your users. Conversely authoring through Word 2007 will be more familiar (if they aren’t bewildered by the user interface changes there), but has a number of issues. Users might well get annoyed by having the styles they can use restricted down also.

One final thought - frustratingly, as we’ve found, all three methods result in different structures of HTML, and require different CSS to style them up. Consequently, I strongly recommend that you find a suitable method and stick to it.

I’ve got to say, I think that I’ve gone full circle now, and I’m back to the idea that it’s just better to author these pages through the Web Browser. The document conversion service not supporting embedded images is a killer.

Read his post first; this is just my thoughts. Done? Good.

Robert Bogue makes some good points. I totally agree with him on the second point - Workflow History isn’t an Audit. However, this does sort of highlight the crux of the issue - that there is no Audit. One is mentioned in his previous post, but I’ve never managed to figure out what he meant by that, or to find a decent audit in Workflow that I didn’t have to build myself. And I just keep thinking that this is something that a plug-in tracking service ought to be able to provide…

I guess my ‘What were they thinking!’ isn’t that there is the auto-cleanup, but rather why didn’t Microsoft offer an audit mechanism out of the box. I asked Lawrence Liu about that once at a SUGUK meeting - he said that SharePoint Workflow “wasn’t intended to be an enterprise solution”. Fair enough, if that’s what they want to do (and to leave space for the likes of K2 and Skelta), but then stop advertising SharePoint as having user configurable workflows.

A number of our customers have gone through the logic of:

1. SharePoint is an Enterprise level system
2. It has workflow built into it
3. Therefore we can use workflow to support our enterprise’s processes

They’re pretty disappointed to discover that it lacks pretty basic things like audit. I can’t say I blame them either. But I digress.

Regarding his first point about configuring the timeout - writing an application isn’t a good general option. I’ve no doubt it works, but SharePoint administrators are necessarily programmers. Even if they are, there’s no guarantee that they’re good SharePoint programmers. The setting in the manifest - that I like. Don’t depend on your users being able to code their own solutions. Further, I don’t know how this would apply to SharePoint Designer workflows, though personally I steer clear of them.

So yes, I’d agree with Robert - it’s not a ‘Huge Issue’, but it is a problem.

However, they’d like a nice column with a little Paperclip icon if the Email has attachments. For normal Lists, there is a column like this (provided that the List allows attachments)…

This shows two list items, one of which has attachments, one of which doesn’t. Indeed, the one with attachments has multiple attachments (a feature that I often forget!)

And we can edit these attachments…

Or add attachments to the List Item which doesn’t have any…

Okay, so Lists can can List Items with Zero to Many attachments. I then went and looked at document library though - and couldn’t see an ‘Attachments’ column…

Trust me, I looked through all the settings and columns available in the views, just in case. The reality is, though, that the reason is pretty obvious - Documents implicitly have one attachment - the document itself! Thus an ‘Attachments’ would just show a series of little paperclip icons - which isn’t dreadfully useful… …and this is why Documents libraries and the like doesn’t show that column.

Even if a SharePoint system is developed to be accessible, there is a governance issue in make sure that new content is also accessible. HiSoftware provide the Accessibility Kit (for free) to help develop an accessible site - though custom work will always be required. They also provide several commercial products to facilitate governance of new content and ensuring that it is accessible. I think that these will be useful sometimes, so it’s not a bad sales pitch.First off it would be good to ask, what is accessibility? Well, accessibility is making a program or web site work for people with a wide range of interaction devices. At one level, making a website work in Opera is making it more accessible; however, usually accessibility is used to refer to making a website work for users with a range of disabilities. For example, a website that showed a video might have a transcript of the speech, or images that have “alternate text” that screen-readers can read to blind people. Colour is also an important issue - you’ve got to make sure that a site will work for various different types of colour blindness. So is text size - SharePoint uses a ‘fixed size’ font, so visually impaired users can not make it bigger or smaller in the browser, and this is a big no-no. For example, these images show a typical SharePoint system in IE7 with the text-size in the browser set to biggest and smallest:

As you might notice, some of the content changes size - but more of the text on the page, including all the navigation, doesn’t.

Accessibility is a complex subject as users could use all sorts of weird user interface devices, such as text only browsers, screen-readers, Braille displays, etc.. Consequently, accessibility always has a question of how far you go. Certain ‘levels’ of this are embodied in the WCAG 1.0 ratings ( A, AA, AAA, etc. ) by the WAI.

What HiSoftware have done is produce a toolkit that fixes a number of these issues (or, at least, makes it easier for you to fix them). It isn’t a solution - you don’t just plug it in and suddenly you’re accessible. In fact, there isn’t anything in it that I don’t think I could program, but their point is simply “why reinvent the wheel”. It’s a good point, and I certainly think that we can find a use for it.

The Accessibility Kit is being developed and released in stages. Stages 1 and 2 have been released already:

1. WCM - Accessibility stuff for WCM sites only
2. Collaboration - Accessibility stuff for collaboration sites (wikis and blogs)

Future additions will include an accessible Rich Text Editor control (neither the MOSS or Telerik ones are). This is something of a Holy Grail. The kit itself is open-source (it would be hard for it not to be), and it is free.

One of the things that I took away was how it’s necessary to treat Accessibility like branding - when a customer asks for an accessible SharePoint system, we’ve got to ask “which bits?” Building a SharePoint System that is accessible throughout is a massive undertaking. If you can restrict the scope of the bits that need to be accessible, then that’s a good idea. For example, why bother making My Sites accessible if it’s only internal users using them, and there is no internal requirement for accessibility?

There are problem areas that we discussed:

• Libraries and lists - as there are some complex user interactions going on in there (List menus, List ordering, Views, View menu, ListItems menu and submenus to name a few)
• Administration pages - the same problem as branding, they’re not really designed to be modified. Note that some ‘Administration’ pages are visible to normal users…
• Web Part Zones - don’t produce good code for screen-readers and the like.

Further, some companies may insist on XHTML-Strict compliance - this isn’t really the same as accessibility, though you can use similar techniques to try and achieve it. With SharePoint this is very hard and (I believe) of limited value.

The biggest thing that got my attention was actually HiSoftware’s sales pitch (but they have a good point - really). Although we can build an accessible site, content will then be authored by the users. It’s unlikely that they know anything about accessibility, let alone how to write so that their site remains accessible. Thus, we need to have some way of ensuring compliance with accessibility rules, guiding users in how to fix content, locating content that needs fixed on the site, etc.. This then brings us into contact then with the world of compliance too - make sure that, for example, rude words aren’t used in the content. HiSoftware produce a number of tools to help do this:

• A plugin for SharePoint Designer to help designers make accessible pages/page layouts, etc..
• A feature for SharePoint to allow content authors to test the pages they’re writing
• A program for crawling and checking accessibility and compliance of your site
• Processes and workflows to support enforcing compliance (sort of like advanced ‘Content Approval’ workflows, but allowing things like users to pass content to a technical team if they don’t know how to make it comply).

See their MOSS solutions page for more details. HiSoftware seem to have come to SharePoint from a website accessibility and compliance management background and have realised that this is something missing in SharePoint 2007…

Instead, you have to insert them as linked objects :

Objects such as images that you add to your Word 2007 document will not appear on the converted Web page if they are embedded in the document. To add these objects so that they appear on the converted Web page, first upload these objects to a document library and then insert them as linked objects (from this location) rather than embedded objects in your document.

There are some instructions here, but this is my guide:

First, find your image on your web page. In SharePoint, this might be a Picture Gallery. Copy the image by Right Click > Copy

Go to Word, and Paste > Paste Special…

Select that you want HTML Format :

And congratulations, you’ve inserted a link to the image on the web server, rather than the image itself:

You should then see a window like this:

Use the left pane to browse your site collection, and the right one to select the item you want to see the related items for. Then click the ‘Related Items’ button:

This should then show you the page with a third pane, showing the related items and the nature of their relationship, where they’re located, and so on…

Sure, there is the ‘Table of Contents’ web part, but annoyingly that shows other things in the site, like lists and libraries, rather than just child sites. And there isn’t any setting I can find on it to make it behave that way - which also seems a pretty obvious feature. So annoying - 90% there, but not quite.

Well Chis Johnson has has the same though and made an example. I’m not entirely convinced about creating the output string in the property (that’s a bit bizarre Chris), but it’s a good start.

I guess it’s another bit of a gripe about out-of-box navigation in SharePoint

The method’s signature is:

Lists.GetListItems( [List], [ViewName], [Query], [ViewFields], [RowLimit], [QueryOptions], [WebID]);

I’m not going to talk about most of these parameters - you can read about them here. For my query, most of these parameters were Null (i.e. they were unused). However, the [List] parameter interested me. It’s the ‘Name’ of the list, though I prefer using a GUID (a unique ID) for the list.

The lookup column I was using was defined in a different site to the one where I was making the GetListItems call. I’d pass the GUID, and get the correct values back. My call actually was:

XmlNode resultNode = _lists.GetListItems( listGuid, null, null, viewFields, null, null, null);

So, this query was finding the correct list elsewhere in the site collection based only on the GUID. Interesting - I’m not passing a WebID, and the list is outside the site I’m currently using the web services of. This set me thinking - clearly the call was selecting by list GUID against a table of all ListItems in the site collection.

I was a little surprised - then it hit me - the Content Query Web Part also does that. But how?

Well, a bit of searching later and I found the SPSiteDataQuery object. The object is used for queries against multiple lists in multiple sites. You can specify the types of list to query, values to filter, order by, display, etc.. I’m pretty sure that this is what the Content Query Web Part uses.

Neat! Now I just need to find a reason to use it!

Unfortunately, SharePoint Publishing features don’t really do this very well. Yes, in a document library it does breadcrumbs as you navigate through folders - but you can’t really do that with Pages. For a start, you can’t put folders in pages libraries!

So, instead, they’ve got this deep structure of sites - just to get the navigation. The site permissions and features are the same at all levels. This is a real administrative pain - especially if want to change the definition of the content types used in the pages libraries throughout the site.

What would be better would be to have navigation providers which show Folders in the navigation - so that they’re exposed in the left navigation (and maybe the top - I’m not sure). You could then enable folders in your page library. Users would then be able to navigate down through folders and pages. I guess there is a question as to which page should be the ‘default’ for a folder (obviously the folder itself isn’t a page that can be shown) - but perhaps something like just having a convention that the page ‘default’ is shown would be enough. Or maybe make it part of the metadata for a ‘Publishing Folder’ content type.
This would mean that the whole deep heirarchy and dozens of sites my customer is using could be dealt with in one single site. I can’t quite believe that nobody had this idea when they were planning the WCM features for MOSS. I don’t even think it’d be that hard - I just hope that I get a chance to implement this sometime…

I can deal with the fact that the Admin UI isn’t as good as it was - although the Dashboard has improved - but authoring posts has got worse:

• Uploading an image - didn’t work out of the box. I had to install a plugin to make that work. Now it reports that the upload failed, though it succeeded.
• Image thumbnailing is not as good - my thumbnails keep getting their left and right edges cut off.
• Creating links in the WYSIWYG text editor just shows me a blank box - I have to switch to edit HTML view and put them in there.

Come on chaps, this isn’t release ready - you shouldn’t have been advising users to upgrade yet. Everyone, steer clear until these issues are fixed. Perhaps it would be a lot easier to not use Flash, eh?

Previously, I found that the document conversion service doesn’t map site column data from the Document type to the Page type. So, what are our options?

1. Get users to fill in the metadata for the converted document
2. Put the metadata into the Word document
3. Bespoke coding
4. Don’t use the conversion service

Let’s look at each in turn.

Get users to fill in the metadata for the converted document

Well, the first option is pretty obvious - get the users to fill in the Site Columns for the converted document’s Page. In my case, this would mean filling in the AWBText column on the ConvertableDocumentPage type. This will work! Unfortunately this means that the page and document’s data is not linked - a change in the AWBText field won’t be replicated between both items, or even just pushed from the ConvertableDocument the next time it’s converted. That sucks a bit, but this might be a valid option.

Put the metadata into the Word document

The second option is quite neat - Word document can have ‘Quick Parts’ - some of which are document properties, and this can be connected to the columns of the content type:

You can put these into the document itself. They’re like document ‘Fields’ in Word pre-2007, but these are much, much better. For a start, you can actually type into the quickpart and it’ll update the document properties - and when you save the document to SharePoint it’ll update the columns of the library! Very cool. Anyway, I updated my Word template from my previous example…

I then created a new document. Note that the AWBText field in the Document Information Panel and the Quick part is linked - I typed in the value in the document and it was reflecting the Document Information Panel.

I then converted these document. This resulted in:

Okay, so I’ve scribbled on this a bit. The area outlined in the purple-pink colour is the content of our document that we converted. You can see that this includes the value of the ConvertableDocument’s AWBText column. Hurrah! However, above this is the value of the AWBText column on the ConvertableDocumentPage - and it is still empty. In other words, the original document’s metadata is now in the page content - but it still isn’t stored against the Page as metadata. This isn’t really suitable for our customer - they need that column data against the Pages for their navigation. Bah!

Bespoke Coding

Okay, I started to wonder if I could fix this via custom code (i.e. some sort of Feature). I dug through some of the hidden properties of my source ConvertableDocument and destination ConvertableDocumentPage using SharePoint Manager. I knew that there must be some sort of connection as if you Edit the ConvertableDocumentPage is shows you that is has a source document, and lets you edit that document instead. Therefore, they must know where they came from.

In SharePointManager, I found some interesting fields. The ConvertableDocument content type I’d created had a property RcaPageID, which was a GUID. ‘Rca’ stands for ‘Rich Client Authoring’, which is what they seemed to call this page authoring technique until some decided to call it ‘Smart Client Authoring‘ instead. Certainly, internally it’s normally referred to as Rich Client Authoring, or ‘Rca’.

I then checked the ConvertableDocumentPage type, which had a property RcaSourceDocID . This was a GUID, and this ID matched the RcaPageID of the document we used to create the page. Thus, and I’m pretty sure about this, it’s the connection between the source Document and destination Page.

Therefore, I could build an event handler that (when a page is updated or created) gets the Page’s source document, sees what columns they share, and copies across the values of those shared columns. Actually, it’d probably have to exclude some (like title), but you get the idea. Also, it’d have to run a query across all the documents in the site collection, but I’m pretty sure that this is possible.

I like this solution, and think it’s a fairly straight forward, generic candidate for a feature, but unfortunately our customer is unable to make server configuration changes - like installing new features. So that rules that idea out… damn.

Don’t use the Document Conversion Service

I know, this seems a bit crazy - but you could author your content in Word and just copy and paste the content into your pages. This is what our customer was doing. I know, it seems a little crazy to me too, but if you lock down the styles available in a Word template, then the code you’ll copy will have consistent CSS styles in it, and you can prevent any inline CSS through that restriction too. It has no server footprint and no duplication of metadata - but you still have to store the documents (which might require column data too).

So those were the options I was able to come up with. I like the coding option - an event handler could be a very elegant way of dealing with this.

One of our customers wants to author their Pages in SharePoint in Word. Sounds like a case for the Document Conversion Service - author the content in Word, and then convert the Document to a Page. There is a catch though - they’re wanting to capture some meta-data about the document too, such as business unit, review date, department that ‘owns’ the page, etc.. What would the Document Conversion Service do with this information? I didn’t remember seeing any way of setting up mappings between fields. Would the metadata be copied if both the Document and Page content types shared the same site column?

To find out, I did a bit of testing. Much of what I did was actually stuff like creating a new Page layout, and then customizing it. There are better articles about this that my notes, but I’ll include all the steps. (I do assume that you have the document conversion service running and enabled on your site collection though.) I did the following:

I created a new Site Column - I called it AWBText. It was just a text column.

I created a new Document content type which used that new column. I called this content type the ConvertableDocument content type:

I then created a new Page content type. I called this the ConvertableDocumentPage content type:

I made sure that that also used the AWBText column - and the out-of-box ‘Page Content’ column. This column will hold the content of the converted document. You should probably add another column for holding the style information, but I didn’t bother (’cos I didn’t need it for the test). You could create your own, but I chose just to use the same ones as the Article Page content type - after all, the data (page content) is still the same, and this is why different content types can share the same columns.

So, now I’ve got my two content types I’m going to test with, and they both share the AWBText column. However, the ConvertableDocumentPage content type needs a page layout to, well, define how the ConvertableDocumentPage’s content will be displayed. I cracked open SharePoint Designer, opened my site, and created a page layout:

This gives you a page layout to put your content controls into. We’ve only got a couple:

I created a page layout. Here’s the code and how it looked in SharePoint designer:

As you can see, I’m displaying my AWBText field at the top, with the converted content from our converted ConvertableDocument below. Both fields also have labels. I published and approved the layout.

Next, I set up a template Word document - I went to the ConvertableDocument content type’s advanced settings, and edited the template.

I then just saved the template without making any changes - I’ve found that you need to do this to get the Document information panel to work correctly.

Next up, I set up the document conversion through ConvertableDocument content type’s settings:

Then the complex form of the conversion setup:

Take a moment to look at that form. I’ve defined that I want to convert my ConvertableDocument to a page layout of ConvertableDocumentPageLayout - which implies a content type of ConvertablePageLayout. I’m putting the content of the converted content into the Page Content column, and removing any styles (because, as mentioned above, I don’t have a suitable column to put the style information into). Note that there are no settings for other data mappings - no columns of the document to columns of the page mapping.

I saved these settings, added my ConvertableDocument type to a Document Library, and added my ConvertableDocumentPage type to the ‘Pages Library’. Then I created an example document. Note the Document Information Panel at the top shows my AWBText column (and the Title column), and I’ve put in some text.

I saved this, and in the document library I chose to convert the document to a web page:

This resulted in a page that looked like:

And the document library looked like:

So, as we can see, the AWBText column has not been copied across, even though it is the same column. During the configuration process, there was no option to configure mapping of fields. It looks like the Document Conversion Service doesn’t map column data. In Part II, I’ll look at some options.

I found what I can only describe as a but in the Lists.asmx web service in SharePoint. I was using Lists.GetListItems to get a list of the folders in a Document Library, and I found that I was getting one of the folders twice. However, when I looked in SharePoint, there was only one, and my program showed that both these folders were supposed to be at the same URL. WTF?

Naturally, I went back and had a look at the XML I was getting back from the web service. I expected to get two, so I was somewhat surprised to get 3…

As you can see, 2 records have the same URL, the same internal ID (both of which have to be unique!), and the only difference is in the AWBMultiLookup column. This set alarm bells ringing. Firstly, I was surprised to see it in the results. In GetListItems you can define the fields you want returned in the responses (the ‘view fields’ ). I had only asked for the URL, the ‘link file name’ (the item’s name), and it’s ID. I’d expect to get some other details (the web services always seem to include more), but not field data.

Secondly, AWBMultiLookup is a multi-select lookup column. In other words, it looks up data from another list, and you can can select zero to many items from it. For my folder, I’d selected 2 options from this column (’A’ and ‘C’), and now I have 2 records with the only difference being the value of the AWBMultiLookup column - ‘A’ or ‘C’. On a hunch, I went and selected a third option (’B'), and my XML I was getting back became:

Yup, now I got 3 records with different values of AWBMultiLookup, rather than just the one. Clearly, and incredibly, the web service was returning a seperate ‘item’ for each value of the multi-select lookup column that was selected. I can’t think of a situation where that would be the desired behaviour - and everywhere else in the system, multiple values are just encoded into one string. Hence, I’m calling that a bug.

However, this raised a question. Elsewhere in the system I get just the one folder and it was definitely getting the multi-select lookup field correctly. I ran that code and found that the XML I got back was:

Yup, you’ll notice that the results from GetListItems this time shows all the values for the multi-select lookup in one attribute. What gives? What’s different about this query to the other one where multiple items would be returned?

Well, the only difference that seemed like it could be relevant is that this second query requests the ‘AWBMultiLookup‘ column in the ‘view fields’. I decided that I’d test this by modifying the view fields for my first query to include the AWBMultiLookup column like so:

Having done this, my query now worked as I’d expected it to in the first place:

Notice that all values are now encoded in the one attribute, and that I’m getting the two records I’d originally expected.

Or course, this doesn’t help me. When my application is browsing across folders I don’t actually know what the columns against folder really are, so even if I was happy to request the multi-select lookup fields (despite their being superfluous ), I can’t, ‘cos I don’t know what they are yet. I’ve gotta admit, though, that I’ve lost my temper at whoever made the web services work that way. It’s worth noting that the SharePoint API doesn’t behave similarly

One thing I haven’t checked yet is what happens if you hav many multi-select lookups. Combinatorial explosion anyone?

Quite a lot of your default master page is in ContentPlaceHolder controls. Those ContentPlaceHolder controls have default content - but your page layout can define Content controls which place content into those placeholders, overriding them. Of course, you still need to have all of the appropriate controls on a page - just removing the ‘Site Actions’ menu for everyone isn’t a good idea - but you can do a lot.

This sort of came up at the last SharePoint User Group meeting - Colin Byrne was demonstrating Silverlight in SharePoint (which apparently doesn’t work all that well yet, but shows promise). One of the demos he has showed replacing the left navigation with a Silverlight control, but used a neww Master Page do to that. I thought of a demo I’d done recently where I’d done similar - but with a Page Layout. I used this to replace the left navigation menu with a Web Part Zone:

Normal View

Edit View

Believe it or not, this is actually the default master with a particular Page Layout that I made, and the ‘Simple’ theme applied. Actually, there are lots of bits of the page modified by the Page Layout. The ‘Site Actions’ menu and Top Navigation Bar have been moved up, for example. The Left navigation has been replaced by a Web Part Zone, and I’ve dropped a Content Query Web Part in there for a giggle. And the Search box has been moved down the page too.

You could do all of this with a Master Page of course - and in real life, you’d probably want to for most of those modifications. For some things, though, like replacing certain navigation controls (which is what some of the out-of-box page layouts do with title breadcrumbs) then I think that a page layout might be exactly what you want - so that you can have different forms of navigation for different pages using the same Master Page.

Anyway, I was surprised by how easy it was to do this. Given that the Master Page defines default content, much of what I did was just copy that default content into the Content control for the location that I wanted to put the control into - and voila!