SharePoint has a great API for most things, but some of things seem a bit lacking.
I recently had a need to auto-create folders inside a document library. Basically, like mkdir with command extensions does on the command line. If directory x exists, but x\y doesn't, mkdir x\y\z will mkdir x\y and mkdir x\y\z.
After some struggling, here's what I ended up with:
Public Shared Sub CreateDocLibFolders(
ByVal url
As String)
Using site
As New SPSite(url)
Using web
As SPWeb = site.OpenWeb()
If url.StartsWith(web.Url)
Then Dim folder
As SPFolder = web.RootFolder
For Each segment
As String
In url.Substring(web.Url.Length + 1).Split(
"/")
Dim nextfolder
As SPFolder = web.GetFolder(folder.Url & IIf(folder.Url.Length > 0,
"/",
"") & segment)
If Not nextfolder.Exists
Then folder = folder.SubFolders.Add(nextfolder.Name)
Else folder = nextfolder
End If
Next
End If
End Using
End Using
End SubOkay, I know it doesn't look like much, but that code represents some hard won knowledge. The main thing was dealing with folders that had spaces in them. Before, I was System.Web.HttpUtility.UrlDecode()ing them, but my use of .Name on a .Exists=false proved to be much more elegant. Even though I'm doing a GetFolder on a escaped url, the .Name property returns a nice, suitable for passing into SubFolders.Add(), de%20ed name. But why use this ugly indirect path string building technique? Well, I could not find an exception-free way of doing existence testing of a folder other than web.GetFolder() which, of course, needs a web relative url -- this lead to the more clunky looking GetFolder expression.
RaiseEvent OnReligiousArgument
For the two people that read this blog (me and uh, that might be an exagerated figure) the reason my snippets have been in VB.NET lately is because I think VB.NET is underloved in the SharePoint community. VSEWSS, for example, is a C# only club. Heck with that. It doesn't provide enough juice to justify the opaqueness of its wsp builder. VB.NET has some nice features and I like taking advantage of them -- I know both cold and I make no apologies for choosing VB.NET. If you are one of those C# 1337ists... run the benchmarks and tell me its so much better. Tell me what it does so much better that it makes up for the utter lack of exception filters, XML literals (VB9), pleasant event raising, beyond 1980s-era switch/select case, optional parameters, automatic by-reference parameters for callers, array resizing, and procedure scoped static vars. I'm not saying C# is worse -- it's like the difference between ibuprofen and acetaminophen. Minor advantages in some edge cases both ways but they all fix most headaches.
I've seen some comparisons between the two languages before on the net, but none seemed entirely complete. If I ever am put in jail with nothing but a toilet and a laptop for a few years, perhaps I'd blog /the/ definitive list.
For those of you thinking of writing in your reasons why C# is soooo superior to VB.NET, please refer to the
Logical Fallacy article on Wikipedia before embarrassing yourself. Reasons like "real programmers use semicolons" or "only a moron would use a language with the word 'basic' in the name" will be ridiculed mercilessly. There are some valid arguments for C# and one could make an equally compelling valid case for it over VB.NET.