Introduction to Composite UI Application Block (CAB)
The Composite UI Application Block is a new application block (well, not so new; CTP in december) that makes it easier to develop windows applications. It creates separate loadable modules that are dynamically ran in the application, working with a new object called the WorkItem. The WorkItem is basically a class that can be considered a unit of work. It can handle whatever you want to do, such as setting up the user interface, retrieving data from the database, or whatever else you want to do.
Specifically, in one of my C# solutions, I have two projects:
MainApp - compiles in MainApp\bin\Debug - Main project
CABApp - compiles in ..\MainApp\bin\Debug - Separate project to do whatever
The reason you redirect the CAB application to compile in the MainApp's bin folder is because CAB dynamically loads the CABApp module. It knows this because it looks for a ProfileCatalog.xml file in the MainApp folder, which has this declaration:
<SolutionProfile xmlns="http://schemas.microsoft.com/pag/cab-profile" >
<Modules>
<ModuleInfo AssemblyFile="CABApp.dll" />
</Modules>
</SolutionProfile>
A word of advice: make sure that the ProfileCatalog.xml has a Copy to Output setting of Copy Always or Copy If Newer, so it is available at runtime. When the MainApp runs, the CAB Application loads a custom module that Inherits from ModuleInit. So in our CABApp project, we need a CABModuleInit class that does this:
public class CABModuleInit : ModuleInit
{
private WorkItem _workItem = null;
[ServiceDependency()]
public WorkItem WorkItem
{
get { return _workItem; }
set { _workItem = value; }
}
public override void Load()
{
CABWorkItem workItem = this.WorkItem.WorkItems.AddNew<CABWorkItem>();
workItem.Activate();
}
}
It is responsible for loading the custom work item into the work items collection and activating it. Note the [ServiceDependency()] attribute, which is a new feature called Inversion of Control, or IoC. You can
read more about IoC here. I won't go into specifics here, but basically, dynamically at runtime, an instance to the work item is provided to the setter of the property. With CAB, you will see this application design approach throughout. Continuing on, our custom work item looks like this:
public class CABWorkItem : WorkItem
{
protected override void OnActivated()
{
//Do whatever, load custom API items, load data, etc.
}
}
Basically the work item is a unit of work. It is tasked to do whatever you need it to do. There are other benefits, but this is the basics to building a custom CAB module. I'll be talking more about CAB in future posts. In my applications, I use these modules to interact with an application object model I created for my application.
Typically, the CAB application has a group of user interfaces and UI code to interact with the main form. In my application, I use an object model to load the UI elements and objects into the API, which loads it into the application, all initially setup from the work item. But you can use it to do whatever you need to do.