One of my interests lies in structuring SharePoint code in a such a way as to support development using a typical SDLC process. That means being able to place many, if not all, of the customizations done via the browser into source code control. Furthermore, it's much too often that I see SharePoint code not following standard ASP.NET design patterns, and as a result most of it remains untestable, and untested. If SharePoint development is at it roots, and for the most part, simply ASP.NET development, then why can't we follow adhere to the traditional patterns of ASP.NET development? Throughout the next several posts, I hope to dive deeper on this topic, but for now, I'll focus on the task at hand, "Featurizing SharePoint".
A couple of weeks ago at the Office Developer Conference, Andrew Connell demonstrated a custom extension to the SharePoint STSADM. After generating content types from within the browser, a user could run this utility and then extract the XML required to create a SharePoint feature. The benefits of this? Well, this is huge in the world of SharePoint development. As a SharePoint developer I often find myself struggling with adopting SharePoint to a typical SDLC process. How do we "check-in" a list, or a custom content type that has been created in the web interface? How do we deploy such changes in a repeatable, predictable fashion? Andrew did a great job on presenting "A Structured & Repeatable Approach to Building Microsoft Office SharePoint Solutions", a topic that the SharePoint developer community has failed to adopt. It's all too easy for a developer to throw together a list or content type in the web browser, and the hope and pray that this content moves from development to production without a hitch. What about if you have an offshore team developing SharePoint components? Well, I did and it wasn't until I learned the hard way that moving web content repeatable relied on the use of things such as site definitions and features.
So if features are the answer to all problems, then why don't we all adopt this approach? Well, who has ever sat down and wrote a view in CAML, or started typing out all the pages and pages of XML required for a list definition? Certainly not me. Wouldn't it be nice to have a graphical interface where we could design all of these components? Microsoft has given us this wonderful interface called Internet Explorer. Why not use the browser to create all of these lists, content types, etc. and then grab all of those changes from the content database and generate your XML? Well, for starters, we don't have a nifty way of telling the STSADM "go and generate a list feature for this list on port 8888". Notice I said port 8888, because we do have a utility called the Microsoft SharePoint Solution Generator, but it only works on sites that are on port 80. Furthermore, I have not had very much luck using this utility, since it adds a lot of unnecessary attributes inside of the XML files.
So anyway, my goal here is to create an extension for the STSADM, much like Andrew's utility, but that will extract list definitions for you. Luckily, I have found a blog entry by Alfred de Weerd that talks about such a utility. I will be working with Alfred to add some additional functionality to his baseline utility and probably try to move it into an extension of the STSADM.
Look for updated posts as I venture into the realm of "featurizing" SharePoint development.
Someone recently posted on the MSDN SharePoint Forum a question on how to programmatically enable audience targeting on a list.
I thought to myself, well this should be easy enough, must be a property on the SPList. So off to MSDN to check out the members of SPList. Scrolled down, up and then down again, and could not find anything. Okay, I'll hit Ctrl+F and search for it. No luck either. So, the next thing to do was figure out what exactly does this setting do. Well if we enable it, and take a look at the settings for the list, we will see that it adds a new column to the list called Target Audiences of type Audience Targeting.
This type is actually added to the existing list content type, so now we just need to figure out what the ID and Type of the field is and we are in business. With the help of a small console application we can see the ID and type of field.
Now it's just a matter of inserting that field into the list with the code below and presto, we have just enabled audience targeting functionality on our list programmatically!
public void AddTargetAudienceField()
{
SPList currentList = SPContext.Current.List;
// Create the field XML that will be added to the list
XmlElement fldElement = new XmlDocument().CreateElement("Field");
fldElement.SetAttribute("ID", "61cbb965-1e04-4273-b658-eedaa662f48d");
fldElement.SetAttribute("Type", "TargetTo");
fldElement.SetAttribute("Name", "TargetTo");
fldElement.SetAttribute("DisplayName", "Target Audiences");
fldElement.SetAttribute("Required", "FALSE");
// Add the field XML and update the list
currentList.Fields.AddFieldAsXml(fldElement.OuterXml);
currentList.Update();
}
Well, I have finally given in... I have created my own blog. After several years of .NET/Office development, I have finally set aside the time to share some of my experiences with the development community, Office developers in particular.