WSS Practice: Create a list, columns and view programmatically

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). Continue reading “WSS Practice: Create a list, columns and view programmatically”

WSS Practice: Create a list, columns and view programmatically

Fast access items in an SPListCollection

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.

Fast access items in an SPListCollection

Property bags are useful – but there isn't one on SPLists?

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.

Property bags are useful – but there isn't one on SPLists?

Dude, whats my column type?

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… Continue reading “Dude, whats my column type?”

Dude, whats my column type?