T4 Triad Pattern

This sample shows how to implement a simple triad pattern for text rendering similar to the MVC / MVP user interface patterns.

When to Use this Pattern

This pattern is useful when text templates have a significant amount of logic. Text templates become very difficult to write and maintain when they have code for workflow, pattern matching on the model, string parsing, and text rendering all bundled into one template. This pattern separates the workflow, pattern matching, and string manipulation into a separate compiled assembly. The text template is only responsible for simple text rendering.

Controller

The controller is responsible for the workflow, as well as other computational tasks like generating camel-cased names. It will iterate over elements in the model, raising events when it needs to render text. The events are declared with simple parameters, like "string propertyName" and "string propertyTypeName". Although there is nothing preventing us from passing the model instance to the template, keeping the template ignorant of the model forces us to create very simple rendering methods and encourages putting all significant logic in the controller.

Note: The events on the controller are not declared using the standard .NET event patten, making them appear more like method calls to the controller. This reduces the complexity of the controller.

Template

The T4 text template is restricted to very simple rendering methods. It does not have any significant logic in code. The T4 template subscribes to events events on the controller using anonymous delegates.

Model

The model in this example is a DSL Tools model created from one of the samples that ships with the Visual Studio 2008 SDK. However, any type of model can be used with this pattern. I have used xml serializable classes created with XSD.EXE for simple DSLs that do not require the richness of DSL Tools.

Alternate Pattern: Use an Interface or Abstract Class as a Base for the Template

The diagram below looks more complicated than the one above, but the resulting code is actually simpler because you do not have a declare delegates and events on the controller, and then create anonymous delegates on the template. DuncanP suggested this approach, and I prefer it over the pattern above.

Controller

The controller is simplified by removing the delegate and event declarations. The Render method is static, taking an instance of the model and an instance of the TemplateBase class.

Template

The template derives from the abstract TemplateBase class, which is used to declare methods that must be overridden on the template. This class is abstract rather than an interface in order to allow for behavior to be added. If there is no behavior to put on the class, then create this class as an interface instead.

Examples

Two examples are on the download tab to illustrate the two variants of the pattern. The code is included in the CustomCode folder of the DslPackage project, as shown below.
--T4TriadPattern.zip shows an example of the first variant of the pattern.
--T4TriadPatternWithInterface.zip shows an example of the second variant.



A note about the example download: This example borrows from the DSL Custom Tool Sample found on Code Gallery at http://code.msdn.microsoft.com/dslcustomtool for creating a Visual Studio custom tool associated with a DSL.