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):

I borrowed one function from the FunctX library to create the camelCased field names. The XSL probably isn’t nearly as clean or optimized as it should be (my XSL is admittedly a bit rusty), but it gets the job done. Here’s one of the two classes (and class files) which get generated at the source directory of the input XML file:

Awesome! It’s amazing how little code was required to get this basic scenario working.

Now we have a single source which defines our SharePoint artifacts and our code artifacts; I love it. Write your fields and content types in your feature and you get class files for free! You’ll note that I’ve added a simple CamlAttribute where applicable. This will prove handy when it comes time to automate construction of the object instance from a SharePoint list item, which we’ll look at next time (for the time being, feel free to modify the XSL and remove the line for it or write an implementation of CamlAttribute).

Again, to reiterate: the goal is make it easy to build applications on top of a SharePoint deployment by adding a layer of domain specific APIs and objects so that a team can be productive while reducing duplication and the ramp up time required to understand the business domain.

Other points for improvement and enhancement (look for these in a future installment):

  1. Parameterize the program.
  2. Consider making it a Visual Studio add-in or a custom tool.
  3. Make it go the other way; in other words: generate the content type and field XML from class files (which would be cool, too).

But even as it is, it’s incredibly useful. On the next installment, we’ll see how we can build more intelligence into the model and make it more useful.

You may also like...

2 Responses

  1. August 26, 2010

    […] As a quick summary, it's common knowledge (well, amongst SharePoint developers at least) that you can associate event receivers with a list template type.  However, an interviewer recently brought to light that one can also associate an event receiver directly with a content type.  This is immensely useful for anyone building custom solutions on SharePoint, especially if you make heavy usage of content types in your design. […]

  2. October 10, 2010

    […] Design Patterns for SharePoint Part 2.5 […]