Basic Question

Topics: CAB & Smart Client Software Factory
Feb 21, 2007 at 8:35 PM
Hi All,
I have started using CAB. Great work.
I have a few questions.
1. I have currently a ShellApplication
2. I create different user controls seperaely as different projects and associate them with Shell using a .xml file

Is it the only way of creati ng a CAB application? Please let me know what is the best way.
Feb 22, 2007 at 1:54 AM
Edited Feb 22, 2007 at 8:58 AM
The shell application reads ProfileCatalog.xml to determine which Module(s) to open.
Is this a good way - yes I think so.

If you take the process one more step you will see that the veiws (or the veiw presenter) will open other views.

For example.
Say you have a list view displaying on your shell. This listview was referenced in ProfileCatalog.xml. But when the operator clicks on one of the items to say "Edit a row" - then that logic is in the listview presenter.
You may have a Modal Edit window for example and the listview presenter creates a new workitem and displays the view. This second view is not referenced in ProfileCatalog.xml

If you search for ProfileCatalog.xml in this forum you may discover way of avoiding the logic if you so desire.

Hope this helps.
Feb 22, 2007 at 4:18 AM
The CAB is specifically designed to allow you to develop applications in a modular and decoupled manner. As such the Shell project should be ignorant of any other modules that want to utilize it.

Is that the only way to develop a CAB application? Well, not really, but to do it any other way wouldn't make much sense. If you need a simpler way to create a Windows Forms application then the CAB is probably overkill for your needs.

The shell application reads ProfileCatalog.xml to determine which view(s) to open.

Not entirely. I think one of the barriers that developers experience when starting to use CAB for the first time is deciphering the lexicon. Here, Allan is using the word "view" when what he really means is "module".

CAB is broken up into a few very basic parts:

(1) The Shell. This is the "host" for the entire application. The shell should be ignorant of any specific implementations - it's just there to provide the foundation: main workspaces, a toolstrip and menustrip.

(2) Modules. These are "projects" in Visual Studio, but a more accurate term is "Assembly". A module is a .dll that the Shell can load if it is configured in the ProfileCatalog.xml file.

(3) WorkItems. These are the dependency injection containers for CAB. Simliar to a Pico container or other DI object. A Module (.dll) can have as many WorkItems as you feel like coding. WorkItems can be constructed in a hierarchical fashion, so it is possible for one WorkItem to have several child WorkItems, and so forth.

(4) View/Presenter Pair. These are the basic visual componets to a CAB application. Views take the form of UserControls and are typically called "SmartParts". CAB is designed to foster the Model-View-Presenter pattern, but you are not beholden to that pattern. If you wished to use a different pattern, or no pattern at all, you could do that. A WorkItem is typically the object responsible for creating Views and Presenters.

(5) Workspaces. Workspaces are the visual spaces where you can display your Views/SmartParts. There are different types of Workspaces for different scenarios.

The key thing to remember is that modules are the main building blocks for CAB application. The shell is actually fairly simple and should remain so. Code should be written and compiled into Modules, and then the ProfileCatalog gets read by the Shell application to determine which Modules to load. So you can remove a Module from your application by simply removing a line from the .xml file, and you can add a Module with the same minimal effort.

In this way, the CAB makes an ideal framework for teams working on an application that has several different parts. Teams can work on different modules without affecting other teams and their code. Modules can be developed in a mostly independent manner. That is part of the real value of the CAB.

Feb 22, 2007 at 9:01 AM
Sorry the word should have been Module and Chris correctly points out.