Okay, this is weird.
I’m trying to do something with various types of item, including Blog Posts, in SharePoint. Naturally, I’m getting the SPListItem for them, and then the SPListItem.ContentType, so I can check what kind of item is it. The weird thing is, if I try to get a Blog Post, the SPListItem.ContentType is NULL. Read more »
This is an example of programmatically creating a content type (based on the Document content type) and adding it to a list. I’ve not added any extra columns or anything – but we could have.
string name = ...
SPList list = ...
SPContentType baseContentType = web.ContentTypes[SPBuiltInContentTypeId.Document];
SPContentType type = new SPContentType(baseContentType,web.ContentTypes,name);
list.ContentTypes.Add(type);
list.Update();
We’ve got a project with an interesting requirement for a Document Library. When the site it provisioned, it will have a number of documents already in it, of a specific content type. Users should not be able to create more documents of that content type. Further, we would be uploading documents via some custom screens which should also be stored as ‘hidden’ document content types.
No problem, I thought – in my Schema.xml for my custom Document library I can specify Hidden=”TRUE” in the ContentType node. Sadly, this doesn’t work entirely well… Read more »
Interesting question came up as a result of a post of Chris O’Briens:
Interesting you raise ContentTypeBinding. I use this in other areas (e.g. associating content types with Pages libraries). Don’t think it had occurred to me that I could use it here also.
Which kinda makes me wonder why the schema provides two ways of doing the same thing, but that could lead to whole ‘nother discussion
Well, I get interested by questions like that. As far as I can tell…:
So, you can use the ContentTypeRef to create a list with a content type, or you can use a ContentTypeBinding to add it later. And you should be able to do it in the same feature – you could use a ListInstance to create a list using your definition, and then bind your content type. And yes, it does rather look like all three bits could be in the one Feature.
I wonder what happens if you try to create a list definition without a content type reference? Might try that for a giggle sometime.
Side note: the Property element on a File element in a publishing site with the key PublishingAssociatedContentType is for associating the file (a page layout) with a page content type, not for associating the page content type to the Pages library. You have to do that as well, using a ContentTypeBinding element. (Thanks Waldeck, that was driving me nuts!)
Pointed out to me by a colleague (ages ago!) – Ton Stegeman’s ‘Content by Type‘ web part. A good way of rolling up content of diverse types, without lots of XSL. If your content type structure is right, may well be other ways of doing this (the content query web part and data view may work) – but this is quite a nice looking tool, and simpler. Need to download and have a play sometime soon.
Aka “CAML is the bastard spawn of Satan”.
So, I’m writing a site definition to create a Publishing site. This is a bit of a first for me. One of the things I want to do is deploy a new Publishing Page Content type, and associate some layouts with it.
I started by following Andrew Connell’s instructions for a Minimal Site Definition (as in his book). This all seemed to go pretty well; testing created a new, minimal site.
Next up I wanted to deploy the Content Type and associated page layouts. Well, there wasn’t much information in his book on this – like him, I’d figured I’d write a separate Feature for deploying just the content type and page layouts – but there was very little information in his book about this. Read more »
I received a good link in one of the comments on the blog, and I thought I’d bump this up – Sensible Document and Template Management.
I’m with Mads on this – to me the killer feature of SharePoint is how it works with Offices, and template functionality is key in that. Demos of document properties, quick parts and then the list columns in Sharepoint have a very high wow-factor (rightly so – I think it’s pretty neat too!)
However, templates are something rarely used in my experience, or not use properly anyway. Often it’s seen as an unnecessary effort, and usually everyone just starts creating their own documents from blank, or deleteing the contents from an existing document and using that one, or copying and pasting across – none of which are pretty scenarios.
Then again, often the guys actually making these templates need a good course of ‘How to use Word’. No so much with Excel – I think that people accept you need a bit of training to use it – but Word seems to be an issue.
Anyway, the point is, do try and plan building templates into your project. And that there is probably a consultancy opportunity in trying to generate these…
More workflow fun – this time caused by my using the latest Visual Studio project for building SharePoint workflows – at this time it’s the one packaged in the VSeWSS3 version 1.2.
Back in the days of RTM, Workflows had a rubbish Visual Studio Project – I mean, awful. “Some assembly required” is really understating it. However, an improved version came along, and it was alright. Sure, there was some fiddling with batch files, but it worked. You could build it, deploy it, and test it easily, and it was pretty easy to get a simple workflow and some InfoPath forms working.
This is my first time using the 1.2 installer, which looks much more sexy – it’s got a wizard and does the ‘deploy’ bit for you, so no fiddling with .bat files. However, I couldn’t get InfoPath forms to appear for my workflow. The were getting deployed into the FEATURES folder, but when I ran the workflows – just ordinary task views appeared.
Bugger. Read more »
Came across something I’d not considered – self referencing lookup columns! I was doing some testing, and this totally caught me out (and caused my Outlook plugin to crash and die).
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.
(For the purposes of this post, I’ll use Pages with a capital P to mean items in SharePoint of a Page content type, or a child content type of Page. I’ll also refer to all content types in italics)
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?
Let’s look at each in turn.
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.
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!
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.
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.
