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();
I like mail enabled lists – they’re not perfect, but they are nice, and most folks can handle working email.
Sometimes, though, you want to programmatically create and enable these lists. That’s cool – but how do you figure out the email address of the list afterward?
You can get the first part of the address from the SPList object’s EmailAlias property. But that’s only the bit before the ‘@’ sign – what about the end of the address? Well, you get that from the farm:
emailAlias = list.EmailAlias + "@" + SPFarm.Local.Services.GetValue<SPIncomingEmailService>("").ServerDisplayAddress;
This gets the rest of the address (in my case ’sharepoint.virtual.local’). Job done.
Tobias Zimmergren tweeted today asking
Anyone got recommendations to how you modify RSS-Settings for an SPList object using the API?
Good question. The SPList object does have a property EnableSyndication that gets or sets whether an RSS feed is available. There is also an property ‘AllowRssFeeds’, but it is, apparently, read only.
So, you can set whether one is allowed or not – but there are a lot more settings. What about controlling them programmatically? Read more »
Being able to mail enable a sharepoint list is pretty cool; once enabled an email can receive email, save attachments, etc.. But what’s the address of the lists? How do you enable it? How are attachments stored, and how do we decide who to let email it?
Well, for a customer we wanted to email enable a list with an address based on the site’s title. This meant that the site would have to be created before we could enable the list. So, I stapled a feature to the site’s definition, and used a feature receiver to run my code. Read more »
An interesting post by Rob Garrett about avoiding using SPList.Items.Add() – as referencing SPList.Items causes you to get all items in a list, and that can be pretty slow. He does suggest a solution.
I must confess, I’m surprised. I mean, what he describes makes sense – and also explains why have both SPList.ItemCount and SPList.Items.Count (same problem – and the former should be faster) – but surely there is some equivalent already build, some SPList.AddItem() to do it for you? Guess not.
Might be a small optimisation, but it starts to become clearer why the 2000 item recommendation…
At some point, I’ll try and generate some metrics, and then we’ll see when it becomes more efficient and how much so.
Next task on my prep – create a list programmatically. Then I want to add some columns to it, and show these on the default view. Actually, it’s mostly pretty easy (apart from that last part). Read more »
What’s the fastest way to access an SPList in an SPListCollection? Well, I can see two alternative ways of getting the list, so I thought I’d test them…
First off, we could get the item by just trying to get it and catching the exception if we fail:
SPList listVariable;
try {
listVariable = mySite.Lists["ListIWant"];
} catch (Exception e) {}
Or we could loop through the lists:
SPList listVariable;
foreach( SPList tempList in mySite.Lists){
if(tempList.Title == "ListIWant") {
listVariable = tempList;
break;
}
}
So, to test this, I built a little test application on the console.
What I found was that loop was always faster. I didn’t try with really large numbers of lists (I only tried up to 20), but I did find that for any probability of the list existing, looping through all the lists was much, much faster (at least 4 times, when the probability of the list we’re looking for was 1; i.e. the list definitely existed!)
There did seem to be a slight load time the first time we accessed the SPWeb.Lists collection, but you have to do that for either method.
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.
Some weird behaviour with SharePoint column types, and the data you get by looking at the SPListItem.properties hash.
So, I’ve got a document library, and I’ve added 3 extra columns to it. For simplicity, I shall call them ‘Text’, ‘Number’ and ‘CheckBox’. I filled in some data for them – a number in the Text field, the same number in the number field, and I check the checkbox for all of the items. I end up with a list looking like below…
So, for now, let’s ignore the fact that the value for some of the longer numbers has been rounded in one of the fields – and not ask why MOSS didn’t just complain that the numbers were too big. Instead, let’s ask what the column types being used are… Read more »
