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

Container 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.

Not all application components require the same visibility and life cycle. A smart client application manages instances of different components, such as services, event topics, commands, work spaces, and UI extension elements. The instances that are closely related should be created together and disposed of together. The related instances of these components must be able to access each other, but they must not be able to access unrelated components.

Place related components in containers that form a hierarchy. A container is an object that encapsulates and tracks zero or more components. The term "encapsulates" in this context refers to logical containment.

The container hierarchy can be used to control both the visibility and the life cycle of application components. Consider the example container hierarchy illustrated in the Figure 1. In this diagram, the container c1 is the root of the hierarchy and is the parent of c2. Container c2 is the parent of c3. Container c1 encapsulates components a and b, container c2 encapsulates components c, d, and e, and container c3 encapsulates components f and g.


Figure 1
Container hierarchy

Components can be added to and removed from a container. When a container is deleted, all its components are also deleted. The delete operation cascades down the container hierarchy. For example, if c2 was deleted, c3 would be automatically deleted. The components for c2 and c3 (c, d, e, f and g) would also be deleted.

A component can access any other component that is in the same container. To access a component in another container, you can use the Parent and WorkItems properties to traverse the container hierarchy. However, the recommended way to communicate between components in different containers is to use events. When you declare an event, you can specify the visibility of that event. There are three scopes of event visibility:

  • Container. This event is visible only to other components in the container.
  • Container and all its children. This event is visible to components in this container and to components in all containers that are a descendent of this container.
  • Global. This event is visible to all components in all containers in the hierarchy.

A Composite UI Application Block WorkItem is a container. The WorkItem class has a property named Items, which is a collection of components. The Items collection includes child WorkItem containers. Logically, a Composite UI Application Block smart client application is a WorkItem hierarchy. The root of the hierarchy (referred to as the root WorkItem) is created by the Composite UI Application Block framework when the shell application is created. When a module is loaded into the application, the framework passes the root WorkItem to the module. The module has its own WorkItem, which it adds to the root WorkItem. This means the module WorkItem is a child WorkItem of the root WorkItem.

For an example of this pattern, see the ShellApplication class and the Module class in the reference implementation. The root WorkItem is represented by the RootWorkItem property of the ShellApplication class. The Load method of the Module class creates a new WorkItem (the type is ControlledWorkItem) and then adds it to the root WorkItem container.

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