Design Guidance for Composite Applications for WPF

Overview

The approach to building applications with the Composite Application Library can vary widely from implementation to implementation. Designing a user interface (UI) can become confusing without clear guidance. The majority of the confusion stems from the difference between the design-time experience of monolithic applications and the design-time experience of composite applications.

A monolithic application is an application where all its pieces are combined into a single application. It is designed without modularity—this means the parts are very tightly coupled and cannot be separated or replaced. From a user interface (UI) perspective, the individual screens in these applications are often laid out at design time and statically composed at run time. This type of application is simpler to design because the majority of the UI artifacts are placed on screens during design time and the overall appearance and behavior (look and feel) of the application is easy to see.

A composite application is an application where the UI is dynamically composed at run time. This allows business logic to determine what is shown to the user. It also allows you to add new functionality to the UI with less friction. In these types of applications, only portions of screens can be seen at design time, and the design experience is more focused on creating islands of visual representation that are combined to represent an overall screen. It is the dynamic nature of these types of applications that presents the most confusion to designers because, in many cases, the complete view of the application can only be seen by actually running the application.

The goal of this topic is to provide some high-level guidance to designers when working on a team that is building an application with the Composite Application Library. This topic describes UI layout, visual representation techniques, binding, and resources distribution. After reading this topic, you should have a high-level understanding of how to approach designing the UI of an application based on the Composite Application Library and some of the techniques that can help you create a maintainable UI in composite applications.

Layout

The layout of applications created with the Composite Application Library builds on the standard principals of Windows Presentation Foundation (WPF)—the layout uses the concepts of panels that contain related items. One of the differences in the Composite Application Library is that the content inside the various panels is dynamic and is not known during design time. This turns the design experience upside-down by forcing designers to create page structures that can contain various content and then work on the actual content in another context. As a designer, this forces you to think about two main layout concepts in the Composite Application Library: container composition and regions.

Container Composition

The term "container composition" is really just an extension to the containment model that WPF inherently provides. This term is used here because of the extremely flexible containment model that WPF has. The term "container" can mean any element, including a window, page, user control, control template, or data template, that can contain other elements.

How you visualize your UI can vary from implementation to implementation, but you will find reoccurring themes that stand out. You will be creating either a window, page, or user controls that will contain both fixed content and dynamic content. The fixed content will consist of the overall structure of the containing UI element, and the dynamic content will be what is placed inside a region (for more information about regions, see the next section of this topic). For example, the Stock Trader Reference Implementation (Stock Trader RI) application has a startup window (named Shell.xaml) that contains the overall structure for the application. The window in Microsoft Expression Blend, as shown in Figure 1, shows a fixed portion of the window. The remaining sections of the window are dynamically inserted into the various regions by the modules as the application loads.

The design-time experience is a little limited in this type of application, but the fact that you know content will be placed in the various regions during run time is something that you need to design around. To see an example of this, compare the designer view of the main page in Figure 1 to the run-time view in Figure 2. In the designer view, the page is mostly empty; it has a title and a section header titled Watch List. Contrast that with the run-time view, where there is a toolbar area with a series of buttons, a position area that contains a tab control with position data, and a News and Watch List area that contain stocks to watch and news pertaining to the selected stocks. The differences between the designer view and run-time view demonstrate the challenges designers face when they create applications built with the Composite Application Library. The items cannot be seen during design time, so determining how big they are and how they fit into the overall appearance of the application is a little difficult. Consider the following as you create the layout for your containers:

• Are there any size constraints that will limit how large content can be? If there are, consider using containers that support scrolling.
• Consider using an expander and ScrollViewer combination in situations where a lot of dynamic content needs to fit into a confined area.
• Pay close attention to how content enlarges as the screen content grows to ensure the appearance of your application is appealing in any resolution.

Figure 1
Stock Trader RI main window in Microsoft Expression Blend

Figure 2
Stock Trader RI main window during run-time

Region

The term "region" represents a container that can hold dynamic data that is manifested into a UI representation. A region allows the Composite Application Library to place dynamic content contained in modules in predefined placeholders in a UI container. The power of regions comes in their ability to hold any type of UI content. A module can contain UI content manifested as a user control, a data type that is associated with a data template, a custom control, or any combination of these. Essentially, this gives a designer the ability to create an appearance and behavior for a UI area and then to have modules place content in these predetermined areas. Figure 3 illustrates that the Stock Trader RI main window contains four regions: MainToolbarRegion, MainRegion, WatchListRegion, and NewsRegion. These regions are populated by the various modules in the application—the content can be changed at any time.

Figure 3
Stock Trader RI regions

To create a region, you need to add the RegionManager.RegionName property in XAML to a ContentControl-based UI element or an ItemsControl-based UI element that has built-in support in the Composite Application Library. The value of the name can be anything and will be used by the module developer to determine where content will be placed. The XAML in Figure 4 shows how the four regions are assigned in the Stock Trader RI. If these two types of containers do not provide what you need, the Composite Application Library provides the ability to create region adaptors that can be created to work with any type of UI element. For more information, see How to: Create a Custom Region Adapter.

Figure 4
Stock Trader RI regions in XAML

To demonstrate how modules and their content are associated with regions, see Figure 5, which shows the association of WatchListModule and the NewsModule with their corresponding regions on the main window. The WatchRegion contains the WatchListView.xaml user control, which is contained in the WatchListModule, and the NewsRegion contains the ArticleView.xaml user control, which is contained in the NewsModule. In applications created with the Composite Application Library, mappings like this will be a part of the design process as designers and developers use to determine what content is proposed to be in a particular region. This allows designers to determine the overall space needed and any additional items that need to be added to ensure the content will be viewable in the allowable space.

Figure 5
User control to region mapping

Visual Representation

The visual representation of your application can take many forms, including user controls, custom controls, and data templates, to name a few. In the case of the Stock Trader RI, user controls are predominately used to represent distinct sections on the main window, but this is not a standard. In your application, you should use an approach that is most familiar to you and fits into how you work as a designer. Regardless of the predominate visual representation in your application, you will inevitably use a combination of user controls, custom controls, and data templates in your overall design. Figure 6 shows where the Stock Trader RI used these various items. This illustration also serves as a reference for the following sections, which describe each of the items.

Figure 6
Stock Trader RI usage of user controls, custom controls, and data templates

User Controls

The rich support in Blend for creating user controls makes them an easy choice for creating UI content in the Composite Application Library. As mentioned earlier in this topic, the Stock Trader RI uses them extensively to create content that will be inserted into regions. The WatchList.xaml user control is a good example of a simple UI representation that is contained inside the WatchListModule. This control is a very simple control that is straightforward to create using this model.

Custom Controls

In some situations, a user control is too limiting. In these cases, custom layout or extensibility is more important than ease of creation. This is where custom controls are useful. In the Stock Trader RI, the pie chart control is a good example of this. This control is composed from data derived from the positions and shows a chart of your overall portfolio. This type of control is a little more challenging than a user control to create, and it has limited support in Blend.

Data Templates

Data templates are an important part of most types of data-driven applications. The use of data templates for list-based controls is prevalent throughout the Stock Trader RI. In many cases, complete visual representations can be created using a data template alone, without the need to create any type of control. The News Article region uses a data template to show articles and, in conjunction with an Items style, provides an indication of which item was selected.

Data Binding

The design experience for data binding will mirror that of most dynamic data–driven applications where the data context is not assigned until run time. Of course, this limits some of the designer-specific data binding features of Blend, but it is a reality in most applications of this type.

In most cases, the view will have its data context assigned by the presenter or presentation model, which will expose data and delegate commands that are available for binding during design time. Whether binding to data or commands, a custom path expression must be used in the Create Data Binding wizard in Blend. In the case of binding to data, Figure 7 shows an example of binding to the Articles property, which is a collection, to the ItemsSource property of the ListBox contained in the ArticleView.xaml user control.

Figure 7
Binding to data

Figure 8 shows the technique for binding to a command where the SubmitCommand property, which is a Delegate command, is bound to the SubmitCommand property of the Submit button contained in the OrdersCommandView.xaml user control.

Figure 8
Binding to commands

Resources

Resources like styles, resource dictionaries and control templates can be scattered throughout an application—even more so with a composite application. When considering where to place resources special attention needs to be paid to dependencies between UI elements and the resources they need. The Stock Trader RI solution is shown in Figure 9, with labels indicating the various areas where resources can live.

Figure 9
Resource distribution across a solution

Application Resources

Typically, application resources are resources that are available to an application as a whole. These types of resources tend to be focused on the root application, but they can also provide default styling on a type basis for modules or controls. An example of this is a text box style that is applied to the text box type in the root application. This style will be available to all text boxes in the application unless the style is overridden at the module or control level.

Module Resources

Module resources play the same role as root application resources in that they can apply to all items in a module. Using resources at this level can provide a consistent appearance and behavior across the entire module and also allow for reuse in more specific instances that span one or more visual components. The use of resources at the module level should be contained to each individual module. Creating dependencies between modules can potentially lead to issues that are difficult to locate when UI elements appear incorrectly.

Control Resources

Control resources are usually contained in control libraries and can be used by all the controls in the control library. In terms of scope, these resources tend to have the finest of scope because control libraries typically contain very specific controls and do not contain user controls, which in an application created with the Composite Application Library, usually go in the modules where they are used.