Andy Burns’ SharePoint Blog

One of the problems with SharePoint is that it’s very difficult to figure out what site is specified by a URL. After all, the URL to a particular page contains:

• the Server
• possibly (but not necessarily) a managed path and site collection
• possibly (but not necessarily) a site
• possibly (but not necessarily) a folder (such as ‘/lists/’)
• possibly (but not necessarily) a list/library name
• possibly (but not necessarily) a folder in a Library
• the item itself.

Suffice to say, with all those optional bits, decomposing a URL to find the site is really hard. There is, however, a slightly obscure way of find this. You can create a site collection (SPSite) with a full URL, and then simply call OpenWeb() without any parameters to return you the site (SPWeb):

string path = "http://example/examplesite/_layouts/settings.aspx";
try
{
using (SPSite siteCollection = new SPSite(path))
{
using (SPWeb site = siteCollection.OpenWeb())
//Do something with the site
}
}
}

I found this when looking at the MSDN docs for SPSite.OpenWeb(). Check out the examples in there.

It’s a little weird that the SPSite object remembers information about how it was opened like that. But it is useful to know.

Tags: Sites, SPSite, SPWeb

Knowing when to dispose of SPWeb or SPSite objects is confusing as hell. Well, Roger Lamb has an excellent page showing patterns that can leak memory, and how to avoid them. This should be mandatory reading for SharePoint devs. (Previously mentioned here – but this is a better link)

Tags: SharePoint 2007 Development, SPSite, SPWeb

I’ve built a feature to active branding on a site including master page, navigation and themes, which I’ve been talking about a bit over the last few weeks. One issue, though is that meeting workspaces have a different master page to ‘normal’ master pages, so I need to set them to use a different ‘custom’ master page when the feature is activated. This means that my feature receiver has to ‘know’ if the site it’s being activated on is a Meeting Workspace, or some other site.

What defines the ‘type’ of a site is the template that was used in it’s creation. Read more »

Tags: Branding, Features, Sites, SPWeb

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.

Tags: SharePoint 2007 Development, SPList, SPWeb

You should dispose of SharePoint objects like SPWeb and SPSite. Gotta admit, I hadn’t realised they were disposable.

Tags: SharePoint 2007 Development, SPSite, SPWeb