Smart Client software factory: cab

Document directory

• Publish an event
• Subscribe an event
• Implementation of event Broker
• Component
• Module

 

From ebookProgramming Microsoft composite UI Application Block and smart
Client software factory

 

Table 1-2. Definitions of basic terms
Used in a cab Application

Shell application	The main Windows Forms Application, the outer container of all parts of a cab Application .. the shell application manages the cab startup process.
Shell form	The main Window of the shell application. The generic term shell used on its own usually means shell form, although not always. It usually contains Workspaces and user interface elements such Menus and toolbars
Workspace	The container window for Smartpart owned by a workitem;. The workspace can control How the smartpart is displayed or hidden. The cab provides several standard Workspace classes, and you Can also write your own.
Workitem	A Runtime container of the objects and services used by a discrete part of a cab Application. Think of it as a logical sub-process or sub-application. It is Basic Unit of software scoping in a cab application. Your business logic lives In one or more workitems.
Smartpart	A Visual presentation, a view, of the data owned by a workitem; it is owned by a workitem and displayed in a workspace. A smartpart is Usually implemented as a Windows Forms user control, often containing other Windows Forms controls. Besides displaying the data of a workitem, it often allows User to modify it.
Service	A Supporting class that provides programmatic functionality to other objects in Loosely Coupled way. It usually contains utility methods that are not tied to Specific work item.
Module	A. net Assembly that provides the physical container for workitems, services, and their supporting Classes.

 

 

If Excel is used as an example

 

 

Table 1-3. Cab equivalents of common Ole
Functionality

Cab item	Ole equivalent
Shell Application	Word, the running Program
Shell form	Word's main Window
Workspace	The area on word's main window in which word allows Excel To display its editing window
Smartpart	The editing window created by Excel
Workitem	Excel's business Logic
Service	Ole Libraries
Module	The physical file containing the business logic code, Excel.exe

 

Workitem is a runtime container that contains various components required to complete a use case. components can be visualized or non-visualized, such as smartpart, service, commonds and so on.

The following attributes are defined in workitem:

• Services

Services is a set used to manage services related to implementing a use case. You can add a service to workitem using the following code:

Workitem. Services. addnew <testservice, itestservice> ();

In the code above, the first parameter is the implementation of a specific service, and the second parameter is the interface of the service.

Once a service is added to a workitem, other components (such as smartpart) in the workitem can use the following code to obtain a reference of the service.

Itestserivce service = workitem. Services. Get <itestservice> ();

• Smartparts

Similarly, we can add a smartpart to a workitem:

Testview view = workitem. smartparts. addnew <testview> ("testview ");

We can also obtain an existing smartpart through the following method.

Testview view = workitem. smartpart. Get ("testview ");

Use the following code to display a smartpart In the Workspace:

If (view = NULL)

{

Testviewview = workitem. smartparts. addnew <testview> ("testview ");

Workitem. workspaces [workspacenames. XXXXX]. Show (View );

}

Else

{

Workitem. workspaces [workspacenames. XXXXX]. Activate (View );

}

In this Code, it is not difficult to find that when a smartpart already exists, we do not need to add another instance to the workitem, so that for the same smartpart, only one instance is in workitem.

• Workspaces

The Design of workspaces is the same as that of smartparts. We can obtain the corresponding workspace instance by the unique name of a workspace.

Workitem. workspaces [workspacenames. XXXXX]

• Uiextensionsites

Similarly, uiextensionsites is a collection used to manage uiextensionsite. we can add a uiextensionsite to workitem using the following methods:

Workitem. uiextensionsites. registesite (uiextensionsitenames. xxxx, xxxxxxx;

After adding a workitem to a uiextensionsite, we can add a uielement to the uiextensionsite using the following methods, for example, adding a button on toolbarstrip:

Workitem. uiextensionsites [constants. uiextensionsitenames. buttonsbar]. Add (New toolstripbutton ());

• Commands

The commands set is used to manage commands,

Workitem. commands [constants. commandnames. testbuttonclick]. addinvoker (element, "click ");

Workitem also defines other set variables, such as events, workitems, and items. We will not detail them here.

 

Workitem hierarchy

In cab, workitem has a certain level. The top workitem is rootworkitem, which is unique throughout the application. Rootworkitem is loaded at the beginning of the application. When scsf is used to create a business module, it automatically creates a workitem and loads the module, add this workitem to rootworkitem. The components in a workitem can access other components in the same workitem, and also the components in the parent workitem. The basic access rules are as follows. A component can access the following components:

• In the same workitem
• In the parent workitem
• In grandfather workitem (and so on)

From this we can see that the components in rootworkitem are shared for the entire application. We can activated and deactivated workitem. At the same time, only one workitem is active.

At a higher level, a workitem encapsulates a use-case. The hierarchical relationship of workitem reflects the relationship between usecases in the business. Such a relationship can help us identify the corresponding workitems in the design phase. However, the finer the granularity, the better. For details about workitem design, refer to other articles.

 

Event Broker Service

In cab, we use event Broker service to process communication between different modules. This aims to maintain loose coupling between various business modules. When a cab loads a module, it traverses all the events marked as eventpublications in the module and the Methods marked as eventsubscriptions, and puts them into the event container, all eventtopic instances are stored in workitem. eventtopics set.

Publish an event

In cab, we can add an eventpublication Attribute before an event to publish an event. This attribute has two parameters: event name and event release range. Here we have three release methods:

• Publicationscope. workitem, valid only for this workitem
• Publicationscope. descendants, which is valid for this workitem and its sub-workitem.
• Publicationscope. Global, effective for the entire application and for all workitems

The following example shows how to publish a global event:

[Eventpublication ("Event: // updatesavailable/New", publicationscope. Global)]
Public event someeventhandler updatesavailable;

Subscribe an event

Similarly, we can add the eventsubscribe Attribute before a method to subscribe to an event (the method must be within the event release range ). Different methods can subscribe to the same event. When subscribing to an event, we can specify the thread rules for running this method. There are three optional solutions:

• Threadoption. background, the system will create an independent background thread to run this method.
• Threadoption. Publisher: the execution of this method is synchronized with the publisher thread.
• Threadoption. userinterface, which is executed in the currently activated interface thread. This option ensures that no data is updated during data editing.

The following example shows how to subscribe to an event and process it in the same thread as the current interface:

[Eventsubscribe ("Event: // updatesavailable/New", thread = threadoption. userinterface)]
Public void newupdates (Object sender, someeventargs numupdates)
{
MessageBox. Show (numupdates. tostring (), "updates available ");
}

Implementation of event Broker

In cab, the event broker system contains the following classes and interfaces:

• Eventtopic, which defines an event topic between publisher and subscriber.
• Workitem: exposes an eventtopics set, which has a list of registered eventtopic instances.
• Eventinspector: Check all objects or components to see whether event publishing and subscription (eventpublication or eventsubscribe attribute) exists ). If yes, register publications and subscriptions to eventtopic, and add eventtopic to workitem. eventtopics set.

Command

When we process interface events, we often encounter different interface elements to process the same events. For example, we define an openfile menu option to open a file, at the same time, define a button on the toolbar to open a file. These two interface elements process the same business. In this case, we can use the command mode to process such a design. In cab, we can write an event processing method to bind this method to multiple interface element event processing.

[Commandhandler ("testbuttonclick")]
Public void ontestbuttonclick (Object sender, eventargs E)
{
MessageBox. Show ("successful ");
}

The code above defines a command processing method. The commandhandler attribute "with a command name" is used to declare that this method is used to process the command named testbuttonclick. We can bind a command to a uielement event using the following methods:

Workitem. commands [constants. commandnames. testbuttonclick]. addinvoker (element1, "click ");
Workitem. commands [constants. commandnames. testbuttonclick]. addinvoker (element2, "click ");

Here, the parameters element1 or element2 are the uielements we want to bind, such as a button and menuitem. We can see that different uielements are bound to the same event handling method.

Reference: Command patter http://www.cnblogs.com/zhenyulu/articles/69858.html

Module & component

A cab application consists of several modules (DLLs. Each module contains many components, such as smartpart, workspace, workitems, and services.

Component

The smallest unit of a cab application is component, which contains the following types of component;

Visual Element

• Smartparts
• Items (views and controls)

Support for visual elements

• Workitems
• Workspaces
• Uiextensionsites

Non-visual elements

• Commands
• Eventtopics
• Services

Module

As mentioned above, the cab application is composed of modules. Each module is an independent deployment unit. The cab provides a service for Loading modules during runtime. By default, this service uses a file named profilecatalog. XML file to load modules.

When a cab loads a module, it uses reflection to determine whether the module contains a class that implements the imodule interface (usually implemented by integrating the moduleinit class ).

We can use scsf to create two different types of modules:

• Functional Module -- only provides some services to other modules, does not implement a use-case, does not contain a workitem
• Business module-implement a series of related use cases, including workitems.

In the cab, the design deployed by module makes it easy for us to develop an application that is easy to expand. Every module can be defined as a plugin, when a mature application runs on the customer's site, we can easily develop an independent business module based on the customer's needs without affecting the entire application. The relationship between various business modules is loosely coupled. We can use the eventpublisher and subscribe modes to implement mutual operations between modules or call services.

UI elements

For some common interface elements, such as menuitem, toolbar, and statusbar, cab has a unified definition and implementation.

In cab, these unified interface elements are defined as uiextensionsite, each of which is identified by a unique name. A developer (usually a shell Developer) registers an interface element as a uiextensionsite. The following code describes how to register a menustrip as a uiextensionsite:

Rootworkitem. uiextensionsites. registersite ("filemenu", Shell. mainmenustrip );

After successful registration, module developers can use it to add related interface controls. For example, the following code adds a menuitem to the menu bar:

Toolstripmenuitem printitem = new toolstripmenuitem ("print"); rootworkitem. uiextensionsites ["filemenu"]. Add (printitem );

Note: Although developers can directly use rootworkitem. uiextensionsites ["XXXX"] to obtain the relevant uiextensionsite and add corresponding controls. However, this is generally not a good design. It is best for Shell developers to define a set of common Shell service interfaces, in these interfaces, how to add controls to the uiextensionsite is implemented. For module developers, they only need to call related interfaces to add controls to the uiextensionsite, module developers do not need to care about the details of shell implementation. For example, addbuttontotoolbarstrip, addmenuitemtomenustrip, and so on.

Smartpart & workspce

SmartpartIs a visualization component of an application. We can inherit the system. Windows. Forms. usercontrol class to implement this. Once the usercontrol class is inherited, developers can design the interface. Next we need to display the smartpart in the interface (workspace ). The following code describes how to display a smartpart in a specified workspace:

Testview view = workitem. smartparts. addnew <testview> ();
Workitem. workspaces ["testworkspace"]. Show (View );

In the above Code, we add testview to the smartparts set of workitem and display it in the workspace named "testworkspace.

WorkspaceIs a component used to display controls or smartparts. The cab contains the following workspace types:

• Windowworkspace.
• Mdiworkspace.
• Tabworkspace.
• Deckworkspace.
• Zoneworkspace.