This blog describes how TemplateSelector in WPF can be used to dynamically modify contents of the UI. This is particularly useful in a common scenario many ISV's need to support: ability of 3rd parties and users to extend the ISV's data model with their own data columns.

For example, the original application may include a Product table with some columns (e.g. Id, Name, etc.). However, application's users may want to extend that definition to include additional columns. One of the issues that presents is using the data in UI: the UI provided by the ISV obviously has no notion of the new data columns. WPF, through template selector functionality allows the ISV to include these items in their UI.

One of the options on data binding is the specification of a template selector. Template selector is a custom class derived from DataTemplateSelector, which implements a method returning a DataTemplate given reference to the data that needs to be presented. The method can return an existing data template but it can also construct a new data template dynamically and return it. It is the last option that is particularly useful in the ISV scenario. The custom selector can dynamically discover the new columns added by the user, possibly collect additional meta-data about them (from SQL or some other proprietary mechanism used by the ISV) and return a data template, which provides a mapping of the data columns to WPF UI elements.

The attached sample shows how this can be done. For simplicity's sake the sample generates all its source data. Note that the recommended way of creating the new data template is by constructing xaml and using XamlReader. (The alternative, using the DataTemplate class, populating it with data, etc. is not recommended).

Karsten Januszewski and Jaime Rodriguez in The New Iteration (http://windowsclient.net/wpf/white-papers/thenewiteration.aspx) point out the ability of WPF infrastructure (framework and tools) to allow for clear separation between the roles of designers and programmers. They also describe various development workflows this separation supports. I have been experimenting with an approach that separates the roles further and provides more detailed workflow definition.

Roles

The approach allows five distinct roles to cooperate in the development process: architect, developer, designer, tester and UI stylist:

Architect defines the main components of the UI in terms of class interfaces and how they relate to each other. He/she breaks down the application into Views, Presenters and Data providers. Views will be implemented as User Controls or Windows, Presenters and Data Providers as regular, non-WPF specific classes. The definition is expressed as one or more VS.NET projects containing the definition of these interfaces.

Tester defines the unit tests and test cases exercising these interfaces.

Developer writes the code implementing the above interfaces, providing both UI specific and business specific logic (in separate classes).

Designer determines the layout logic, i.e. the type of layout containers and controls needed. It’s important that the designer limits his/her work to just the choice of the type of controls and how they contain each other NOT to their actual sizing or placement in terms of margins/paddings/widths, etc. That work will be done later by the UI Stylist. The Designer also uses data-binding to define data movement between the UI and the Presenter interfaces defined by the Architect. He/she also adds the references to the events exposed by the View interfaces.

UI Stylist completes UI design primarily in terms of esthetics and usability: adds layout parameters (e.g. margins, min/max sizes, alignments), modifies appearance of controls (styles, templates) and other parameters which do not affect the functionality (particularly code) of the application.  UI Stylist creates Resource Dictionaries.

Components

This approach uses the following concepts typically found in UI applications: View, Presenter, and Data Provider (references to Silverlight are to Silverlight 2 beta).

View is a class derived from a FrameworkElement (usually UserControl); it is usually compiled from XAML and code-behind. The View class exposes WPF/Silverlight events using a WPF/Silverlight-independent delegate. These are then consumed by the Presenter, which in turn uses them to operate on the Data Provider. There is a 1:1 relationship between a View and a Presenter, although both may in turn be broken down into other Views and Presenters.

Presenter is a class that marshals data from and to data providers. It shields the View from knowing the data provider format and behavior and vice versa. It usually has no knowledge of WPF or Silverlight, though it may make use such generic classes as Brushes for colors. In this approach, the View creates the relavant presenter as its Data Context at load time.

Data Provider is a class or collection of classes that handle movement of data to and from the application (to database, WCF service, etc.).

Workflow

This development approach is broken into five steps.

Benefits

This approach allows clear separation of responsibilities between different roles involved in the development: each role works on a different VS.NET project or source file, using tools specialized for the role. Each role can develop and focus on different skills and know-how: architetural and functional requirements, UI layout, code and appearance. Much of the work of each role can be done in parallel to the others.

I am now experimenting with how best to use Command pattern in this approach. If this first attempt at blogging does not lead to my emotional ruin, I may write some more.