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.