Export (0) Print
Expand All
This topic has not yet been rated - Rate this topic

Workspace Hierarchy

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies.
This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Frequently, the visual surface of the client application must contain different views that display data from different parts of the application. An example is an application that must show, side-by-side, a customer list and the details of the selected customer.

Create a hierarchy of workspaces that divides the visual surface of the client into nested rectangular areas like the ones illustrated in Figure 1. In the architecture, which is based on the Composite UI Application Block, the workspace is a work area that can show multiple views.

In Figure 1, the real estate of the client is divided into two horizontal workspaces: the left workspace, A, and the right workspace, B. The right workspace is further divided into two workspaces: workspace C and workspace D.


Figure 1
Hierarchy of workspaces

In the client, which is based on the Composite UI Application Block, the workspace hierarchy is implemented by a simple structure of views and workspaces, as illustrated in Figure 2.


Figure 2
Logical view of a workspace hierarchy

A view (a Windows Form or UI control) contains one or more workspaces. At run time, the application instructs a workspace to show a view. If the view contains its own workspaces, the view instructs those workspaces to show their views. This process continues through the entire hierarchy of workspaces.

Two types of workspaces provide multiple surfaces that appear in the same location. Only one surface appears at a time. These workspaces are the DeckWorkspace and the TabWorkspace.

Frequently, workspaces in a view are separated by a movable vertical and horizontal divider. This allows the user to change the ratio of space allocation at run time.

With this pattern, there is great flexibility in the management of the UI surface. You can create a layout view that defines only a set of workspaces. The application can load other views into those workspaces. By changing the layout view, you can change the appearance and behavior of the client application.

Workspaces are hosted inside their WorkItem containers. This means you must consider the visibility of the workspace and views in the container hierarchy. An application can display a view in a workspace only if the workspace is visible to the view. This also applies when views belong to different modules. For a view in one module to make its workspace available to a view in different module, the first view must be placed in the root work item.

For an example of a workspace hierarchy, see the ShellForm class in the reference implementation. The ShellForm defines two workspaces, the _leftWorkspace and the _rightWorkspace. The AppraiserWorkbenchModule loads the MyAppraisalsView view into the _leftWorkspace workspace, and it loads the AppraisalDetailView view into the _rightWorkspace workspace.

This pattern is related to the Container Hierarchy pattern.

Did you find this helpful?
(1500 characters remaining)
Thank you for your feedback
© 2014 Microsoft. All rights reserved.