Composite UI application Block

The Composite UI application Block builds on the knowledge and feedback gained from the User Interface Process (UIP) Application Block

Flow of Components

In a Composite Application Block application, a WorkItem is a container. A component can access any other component that is in the same container. Components flow from a parent container to a child container.

The root of a composite UI Application Block application is the shell. The shell typically contains workspaces, UI Extension Sites, commands, and services.

The CAB supports the customization of an application using solution profiles in a catalog. A solution profile is a list of modules that should be loaded into an application.

After a module is loaded, it can add elements to the shell's UI Extension sites.

WorkItems
A WorkItem is a run-time container for components that are working together to fulfill a use case. The components can be both visual and non-visual parts of the application, such as SmartParts, controls, and service.

Services
Services are objects that are used by many components in the application.

Module Initialization
When CAB loads a module, it uses reflection to determine whether the module includes a class that implements the IModule interface.

Loading Modules
By default, it uses an XML catalog file to determine the modules to load.

Wiring the Parts Together with the Injection System
To support component independence, a component must be able to use another component without requiring a change to the source code of the component to be used. The CAB application does not create instances of another component by directly constructing an object (using new). Instead, CAB using the attributes such as CreateNew and ServiceDependency. These attribute support the injection of objects at run time.
CAB uses a system named ObjectBuilder to create and inject instances of objects of the appropriate type into the application at run time.

The CreateNew attribute instructs ObjectBuilder to initiate and initialize an instance of an object.

Locating a Service
ObjectBuilder first looks in the current WorkItem, then in parent WorkItem, This process continues until reaches the root WorkItem. If the service is not found, ObjectBuilder throws an exception.

Registering a Service
You can use the Service attribute on a public class to declare a class to be registered as a service in the root WorkItem.

MVC - The view passes user interactions to the controller, which updates the data model. The data model is responsible for updating the view.

MVP - The View passes user interactions to the presenter, which updates the data model. The presenter is responsible for updating the view.

Component
Visual and non-visual parts of an application, such as SmartParts, services, and controls.

Container
A Class that contains components and services.



Design of SubSystems

1. Design of the Application Shell

The class derives from FromShellApplication creates the root WorkItem, which contains the services and child WorkItems within the application.

2.Design of the WorkItem

Container for components consists of SmartParts, controllers, services, UIElements, and other components. The WorkItem provides a Run method that causes the protected and virtual OnRunStarted method to execute, and fires the RunStarted event. You can activate and deactivate WorkItems as required. A WorkItem has a State property, which enables all the components in that WorkItem to aceess shared state. Modifying data in the State property raises the StateChanged event.

3. Design of Workspaces

Workspaces are components that encapsulate a particular visual way of displaying controls and SmartParts.

The CAB includes the following types of workspaces:

a. WindowWorkspace
b. MdiWorkspace
c. TabWorkspace
d. DeckWorkspace
e. ZoneWorkspace

Workspaces can show, hide, activate, or close a set of controls.
All workspaces implement the IWorkspace interface that includes the following members:

-Activate (Objet smartPart)
-Show (Object smartPart)
-Show (Object smartPart, ISmartPartInfo smartPartInfo)
-Hide (Object smartPart)
-Close (Object smartPar)
-Object ActiveSmartPart()
-event EventHandler SmartPartClosing
-event EventHandler SmartPartActivated

WindowSmartPartInfo

This component to specify that a SmartPart should be displayed modally. You add the component to your form, set its Modal property to true, and then pass this instance as the second parameter to the workspace Show method.

TabSmartPartInfo

Specify whether the tab page where the SmartPart will be shown should be activated, as well as its location related to other tabs.

ZoneSmartPartInfo

specify the zone that SmartPart should be displayed in.

SmartPartInfo

It is a generic SmartPartInfo component to specify the Title and Description for a SmartPart.

Design of UIElementAdapters

Shared UIElements that module developers can access are menus, toolbars, status bars, progress bars, sidebars, action panes, the notification trays etc. Shell developers are responsible for the creation of these components, and module developers can create instances of the component and access their properties. Each UI Element requires a specific adapter to handle its manipulation. A string value called the extension site is used to identify elements when interacting with and adding child elements to that site. The application block provides a UIExtensionSites catalog for each WorkItem.

Design of Commands

Enable you to write one event handler that is associated with more than one UIElement, and associate one UIElement with multiple command handlers.
A command can be in one of the three states defined in the CommandStatus enumeration: Enabled, Disabled, and Unavailable.

Design of the Injection Model

1. Design of ObjectBuilder

ObjectBuilder create and inject instances of objects of the appropriate type into the application at runtime.

2. ObjectBuilder Architecure

It uses a pipeline of strategies that allow multiple operations to take palce as objects are instantiated and prepared for use. This allows you to control the order that the processes take place.

3. ObjectBuilder Methods
a. BuildUp method

BuildUp(locator, type, id, instance, policies[] );
BuildUp(locator, id, instance, policies[] );

b. TearDown method

TearDown(instance);

takes an existing object instance and run it back through the strategy chain. This process can remove features added to the object during the BuildUp process if you want to re-use the object.

4. PolicyList
set of policies, each represented by classes that implement the IBuilderPolicy interface, that influence the way that an object is created by ObjectBuilder.

1. Transient policies are those generated automatically by the strategies in ObjectBuilder or through reflection over the attributes on the methods and properties declared in the class file.

2. Permanent policies are those you create by implementing the IBuilderPolicy interface.

5. Pipeline Stages

a. Precreation - occurs before ObjectBuilder creates a new instance of the object.
b. Creation
c. Initialization
d. Postinitialization

Design of the Services

1. Design of the Module Enumerator Service

CAB supports the customization of an application using solution profiles in a catalog. A solution profile is a list of modules that should be loaded into an application. A catalog can contain only one profiles.

The XML file catalog can specify which roles a user running the application must be a member of in order to use the module. You can specify the required role membership for each module in the catalog itself.

2. Design of the Event Broker Service
Enables to implement loosely coupled communications between the components in application.

Available ThreadOption values for EventSubscription are

1. ThreadOption.BackGround - handler should be called on a separate thread.
2. ThreadOption.Publisher - default. handler should be called synchronously on the publisher's thread.
3. ThreadOption.UserInterface - called on the user interface thread, so it is safe for it to modify user interface elements.

3. Design of the Module Loader Service

The ModuleLoaderService uses the information returned from the IModuleEnumerator to determine which modules should be loaded at run time. It then loads the specified assemblies, check them for any ModuleDependency attributes and builds a list of modules to initialize. It instantiates the module initializer for each module and add it to the application shell so that the initializer class can subscribe or publish events and access services added by other modules.

Application Initialization Sequence

Types of Applicaion Classes

1. FormShellApplication
2. ApplicationContextApplication
3. WindowsFormsApplication
4. CabShellApplication
5. CabApplication

1. FormShellApplication

This class is used in applications that need to show a main window as part of their start-up process.

2. ApplicationContextApplication

This class is used in applications that do not show a main window as part of the start-up process, or applications that have complex requirement for creation of the UI before the application starts.

3. WindowsFormsApplication

This class is used in any shell built on Windows Forms. Does not change or extend the start-up sequence.

4. CabShellApplication

This class is used in applications that require a shell (which may or may not be a window) to be shown at start-up.

5. CabApplication

This class manages the fundamental steps of initializing a CAB application. This is the most generic type of application class.

Application Startup Sequence

1. RegisterUnhandledExceptionHandler
2. Create Object Builder and add strategies
3. create the root WorkItem
4. Create and initialize the visualizer
5. Add the required services
6. Add any additional services
7. Authenticate the user
8. Load any services or WorkItemExtensions present in the shell assembly
9. Perform BuildUp of the root WorkItem
10. Find modules enumerated by the catalog and load them
11. Initialize workItemExtensions with the root WorkItem
12. Run the root WorkItem
13. Call the Start method
14. clean up references and dispose of instances

Developing Applications Using the Composite UI Application Block

The basis of a typical CAB application is the FormShellApplication class. You create and instantiate a class that inherits from FormShellApplication, and then call its Run method in your Main routine.
It creating

1. Creating the default RootWorkItem
2. Adding the standard set of services
3. Loading any services and modules that are defined in the profile or configuration of the application.

Override AfterShellCreated to populate toolbars and menus or show user-interface elements.
Override OnRunStarted method to create and display child workItems that need to execute when the application starts.

To show a SmartPart that will be added at runtime

1. Use a SmartPartPlaceHolder control.
2. Add a workspace of a certain visual style.

Basic stages

1. Create a class that inherits from FormShellApplication. In the Main routine, create an instance of this shell class, and call its Run method.
2. Override the AfterShellCreated method to initialize the user interface. You can show different types of UIElements in the shell form by registering extension sites on the tool strip and menu strip where modules can add their UIElements at run-time.
3. Populate any toolbrs or menus in the application by accessing a specific extension site and adding a UIElement to it with the Add method
4. Add container controls to create the layout that is required for your form. Insert SmartParts into these container controls at design-time.
5. Write code for any other methods you need to override.