While working with SharePoint I have stumbled upon quite some inconveniences. Most of the time they were in methods that you don’t use that often, and when you do, you expect them to do something else than they actually do. I probably haven’t worked on a single SharePoint project where I wasn’t instantiating sites. So I was quite surprised when I found out that even something as simple as SPSite.OpenWeb doesn’t always do what you would it expect it to.
By now you should know how powerful the Content Query Web Part (CQWP) provided with Microsoft Office SharePoint Server (MOSS) 2007 is. If you’ve been following this blog for a while it should be really difficult to surprise you with cool new things you could do with nothing more than the standard CQWP. And yet, I think I make a good chance here: did you know that you can use the standard Content Query Web Part to create a tag cloud?
Probably every Web Content Management (WCM) solution out there uses some kind of content aggregation. No matter whether it’s showing the 5 most recent press releases, new job offers or upcoming events: presenting content roll-up to the visitors allows them to get to your content more easily.
Back in October last year I started working with programmatically provisioning Web Part instances. The challenging part was that the assemblies containing the Web Parts’ code were located in the bin directory of the target Web Application. The custom STSADM command I was using for that purpose wasn’t able to resolve the Web Part type. Back then I have found a way to deal with it which I though was a working solution. Unfortunately: just last week I have stumbled upon the same situation: again.
According to the Windows SharePoint Services (WSS) v3 SDK the SPWeb.EnsureUser(String) method is all you need while programmatically working with users. Using nothing more than the login name it checks for you whether the particular user exists in the current web and adds it if required. Within a single line of code it retrieves for you a proper reference to a user no matter the membership/role provider. While it’s really that simple while working in the scope of your SharePoint Web Application, things get slightly more challenging when used in combination with a custom code outside of the HttpContext.