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:
<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Field DisplayName="Model Code"
Name="Model_Code"
StaticName="Model_Code"
ID="{F0000000-0000-0000-0000-000000000001}"
Type="Integer"
SourceID="http://schemas.someusedcarinventory.com"
Group="My Custom Columns"/>
<Field DisplayName="VIN"
Name="VIN"
StaticName="VIN"
ID="{F0000000-0000-0000-0000-000000000002}"
Type="Text"
SourceID="http://schemas.someusedcarinventory.com"
Group="My Custom Columns"/>
<Field DisplayName="Make"
Name="Make"
StaticName="Make"
ID="{F0000000-0000-0000-0000-00000000003}"
Type="Text"
SourceID="http://schemas.someusedcarinventory.com"
Group="My Custom Columns"/>
<ContentType Name="Vehicle"
ID="0x0100FC000000000000000000000000000001"
Description="Used car inventory"
Group="My Custom Content Types" >
<FieldRefs>
<FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType" />
<FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title"
Required="TRUE" ShowInNewForm="TRUE" ShowInEditForm="TRUE" />
<FieldRef ID="{F0000000-0000-0000-0000-000000000001}" Name="Model_Code"/>
<FieldRef ID="{F0000000-0000-0000-0000-000000000002}" Name="VIN"/>
<FieldRef ID="{F0000000-0000-0000-0000-000000000003}" Name="Make"/>
</FieldRefs>
</ContentType>
<Field DisplayName="Dealership Code"
Name="Dealership_Code"
StaticName="Dealership_Code"
ID="{F0000000-0000-0000-0000-00000000004}"
Type="Integer"
SourceID="http://schemas.someusedcarinventory.com"
Group="My Custom Columns"/>
<Field DisplayName="Dealership Fax Number"
Name="Dealership_Fax_Number"
StaticName="Dealership_Fax_Number"
ID="{F0000000-0000-0000-0000-00000000005}"
Type="Text"
SourceID="http://schemas.someusedcarinventory.com"
Group="My Custom Columns"/>
<ContentType Name="Dealership"
ID="0x0100FC000000000000000000000000000002"
Description="Dealerships"
Group="My Custom Content Types" >
<FieldRefs>
<FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType" />
<FieldRef ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Name="Title"
Required="TRUE" ShowInNewForm="TRUE" ShowInEditForm="TRUE" />
<FieldRef ID="{F0000000-0000-0000-0000-000000000004}" Name="Dealership_Code"/>
<FieldRef ID="{F0000000-0000-0000-0000-000000000005}" Name="Dealership_Fax_Number"/>
</FieldRefs>
</ContentType>
</Elements>When approaching this problem, I considered three ways of handling the class file generation:
- 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.
- 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.
- 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:
using System;
using System.IO;
using Saxon.Api;
namespace FeatureToClass
{
internal class Program
{
private static void Main(string[] args)
{
Uri xmlFile = new Uri(
@"C:\Users\Charles\Desktop\elements.xml");
// Create a Processor instance.
Processor p = new Processor();
// Load the source document.
XdmNode node = p.NewDocumentBuilder().Build(xmlFile);
using (Stream stream = File.OpenRead("core-transform.xslt"))
{
// Create a transformer for the stylesheet.
XsltTransformer transformer =
p.NewXsltCompiler().Compile(stream).Load();
// Set the root node of the source document
// to be the initial context node.
transformer.InitialContextNode = node;
// BaseOutputUri is only necessary for xsl:result-document.
transformer.BaseOutputUri = xmlFile;
transformer.SetParameter(
new QName("ct", "http://www.customtransform.com", "namespace"),
new XdmAtomicValue("My.Custom.Package"));
// Create a serializer.
Serializer serializer = new Serializer();
transformer.Run(serializer);
}
}
}
}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):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE stylesheet [
<!ENTITY space "<xsl:text> </xsl:text>">
<!ENTITY cr "<xsl:text>
</xsl:text>">
]>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:sp="http://schemas.microsoft.com/sharepoint/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:functx="http://www.functx.com"
xmlns:ct="http://www.customtransform.com"
version="2.0">
<xsl:param name="ct:namespace"/>
<xsl:output method="text"/>
<xsl:template match="/">
<xsl:for-each select="//sp:ContentType">
<xsl:variable name="classname" select="replace(@Name, ' ', '')"/>
<xsl:variable name="filename" select="concat($classname,'.cs')" />
<xsl:value-of select="$filename" />
<!-- Creating -->
<xsl:result-document href="{$filename}">
using System;
namespace <xsl:value-of select="$ct:namespace"/>
{
public partial class <xsl:value-of select="$classname"/>
{
private string _contentTypeId;
public string ContentTypeId {
get { return _contentTypeId; }
set { _contentTypeId = value; }
}
public <xsl:value-of select="$classname"/>()
{
_contentType = "<xsl:value-of select='@Name'/>";
_contentTypeId = "<xsl:value-of select='@ID'/>";
}
<xsl:apply-templates/>
}
}
</xsl:result-document>
</xsl:for-each>
</xsl:template>
<!--///
Templates
///-->
<xsl:template match="sp:FieldRef">
<xsl:variable name="fieldname" select="functx:lower-first(replace(@Name, '_', ''))"/>
<xsl:variable name="fieldid" select="@ID"/>
<xsl:variable name="dotnettype">
<xsl:choose>
<xsl:when test="//sp:Field[(@ID = $fieldid) and (@Type = 'Integer')]">int</xsl:when>
<xsl:otherwise>string</xsl:otherwise>
</xsl:choose>
</xsl:variable>
private <xsl:value-of select="$dotnettype"/> _<xsl:value-of select="$fieldname" />;
<xsl:call-template name="attribute"><xsl:with-param name="fieldid" select="$fieldid"/></xsl:call-template>
public <xsl:value-of select="$dotnettype"/>&space;<xsl:value-of select="replace(@Name, '_', '')"/>
{
get { return _<xsl:value-of select="$fieldname" />; }
set { _<xsl:value-of select="$fieldname" /> = value; }
}
</xsl:template>
<xsl:template name="attribute">
<xsl:param name="fieldid"/>
<xsl:if test="exists(//sp:Field[@ID = $fieldid]/@ID)">[Caml(Id="<xsl:value-of select='//sp:Field[@ID = $fieldid]/@ID'/>", StaticName="<xsl:value-of select='//sp:Field[@ID = $fieldid]/@StaticName'/>", Type="<xsl:value-of select='//sp:Field[@ID = $fieldid]/@Type'/>")]</xsl:if></xsl:template>
<!--///
Custom functions
///-->
<xsl:function
name="functx:lower-first" as="xs:string"
xmlns:functx="http://www.functx.com" >
<xsl:param name="arg" as="xs:string"/>
<xsl:sequence select="concat(lower-case(substring($arg,1,1)), substring($arg,2))"/>
</xsl:function>
</xsl:stylesheet>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:
using System;
namespace My.Custom.Package
{
public partial class Dealership
{
private string _contentTypeId;
public string ContentTypeId {
get { return _contentTypeId; }
set { _contentTypeId = value; }
}
public Dealership()
{
_contentType = "Dealership";
_contentTypeId = "0x0100FC000000000000000000000000000002";
}
private string _contentType;
public string ContentType
{
get { return _contentType; }
set { _contentType = value; }
}
private string _title;
public string Title
{
get { return _title; }
set { _title = value; }
}
private int _dealershipCode;
[Caml(Id="{F0000000-0000-0000-0000-000000000003}",
StaticName="Dealership_Code", Type="Integer")]
public int DealershipCode
{
get { return _dealershipCode; }
set { _dealershipCode = value; }
}
private string _dealershipFaxNumber;
[Caml(Id="{F0000000-0000-0000-0000-000000000004}",
StaticName="Dealership_Fax_Number", Type="Text")]
public string DealershipFaxNumber
{
get { return _dealershipFaxNumber; }
set { _dealershipFaxNumber = value; }
}
}
}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):
- Parameterize the program.
- Consider making it a Visual Studio add-in or a custom tool.
- 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.