SharePoint Design Patterns: Entry 2.5

In the previous entry, we looked at how we can model a SharePoint list item using a more domain specific model to simplify programmatic access to the list item thus reducing otherwise error prone data access code and making the overall framework easier to use. Again: the idea is to promote reuse and decrease complexity through domain specific code that abstracts the underlying SharePoint object models, making it easier for a team to build functionality on top of this framework.

One interesting point is that if you’re already building your fields and content types using features XML, the work required to generate the domain specific wrappers can be simplified dramatically using automation. In a sense, a content type is basically a class (this is generally how I map them in my domain design); why double your effort and write both the content types and the classes?

So how do we go about this?

(Side note: this isn’t so much a “design pattern” as it is an “implementation pattern”)

As an example, here is a simple XML file which defines a set of fields and content types which use those fields:

When approaching this problem, I considered three ways of handling the class file generation:

1. Use an object model and StringTemplate to create .cs files. This invovled writing POCO classes (or generating them from the schema) which I could deserialize the XML to and then passing those objects to a template instance. This seemed like too much work, given that I really didn’t feel like maintaining all of that code as well. Plus, while StringTemplate isn’t – by any sense of the imagination – hard, it is a non-standard syntax that someone would have to learn to maintain and/or extend the conversion.
2. Use an XDocument and CodeDom to create .cs files. This seemed like even more work! While it’s framework supported, I feel like this solution would be hard to extend and maintain for most developers.
3. Use an XSL transform to create .cs files. This seemed to be the most natural solution given that the source file is already in XML format and a the target content structure is far from complex (the basic class file is fairly simple). Plus, while XSLT isn’t trivial, it’s not that hard either (and the syntax is “standard”).

One of the cool features of XSL 2.0 is the xsl:result-document element which allows you to create multiple documents from one source document. Only one problem: .NET’s XSLT engine doesn’t implement XSLT 2.0! What a bummer; it seemed like if I wanted to get this to work and generate multiple output files, it was going to take some work in code or find an XSLT 2.0 capable processor.

Enter Saxon, which provides an XSLT 2.0 processor for .NET. The following code takes the XML above and uses the xsl:result-document to create two class files, one for each content type:

The code above is a simple console program that takes a (hardcoded) path to a source XML file (a SharePoint elements.xml file) and (hardcoded) namespace and loads an XSL file to transform the XML to C# class files.

Here’s the transform (it’s a bit messy for output formatting reasons, so you’re best off copying it into an XML aware text editor to get a better view):