A common requirement for applications is change the layout
of the Shell depending on certain conditions.

The best way to handle this scenario in CAB is having a DeckWorkspace on the Shell. Then, there might be
different layouts implemented in terms of smartparts
that might be shown under different conditions.

Let’s create a simple example. Think about two layouts: the CRM
layout
and the Transactions Layout. The proposed solution could be
extended to as many layouts as the application needs.

First thing is the Shell. Here we have our Primary Workspace
of type DeckWorkspace.

dl1

Having a DeckWorkspace will
allow showing/hiding different layouts efficiently. This snippet of code shows
how:

private void ShowLayout(){ WorkItem.Workspaces[WorkspaceNames.PrimaryWorkspace].Show(WorkItem.Items.Get(“Layout”));}

Each layout is a single SmartPart

(UserControl). These layouts will hold a ZoneWorkspace.

This type of workspace is well suited for UIs where multiple sources of

information must be shown. It is similar to a Sharepoint

webpage. Working with this workspace is a little tricky. You have to add Panels

and assign those panels a ZoneName. Let’s suppose we

have the following layout for the CRM module:

dl2

The following code illustrates how to show different views

within the ZoneWorkspace for this module.

And also, the same code applies to show a smartpart within the nested TabWorkspace in the same

layout. CAB is intelligent enough to detect that the Layout smartpart

contains instances of IWorkspace and add it to

the WorkItem container so we can use it later.

Finally, the next figure illustrates the layout for the Transactions

module.

dl3

Let’s see some screenshot of this concept implemented with CAB and SC-BAT March CTP.

dl4

dl5

Download the sample solution from here

private void ShowCustomerActionsViews(){ TabSmartPartInfo info1 = new TabSmartPartInfo(); info1.Title = “Summary”; TabSmartPartInfo info2 = new TabSmartPartInfo(); info2.Title = “Tasks”; WorkItem.Workspaces[WorkspaceNames.CustomerActionsWorkspace].Show(WorkItem.Items.Get(“CustomerSummary”), info1); WorkItem.Workspaces[WorkspaceNames.CustomerActionsWorkspace].Show(WorkItem.Items.Get(“CustomerTasks”), info2);}

 

private void ShowCustomerViews(){ ZoneSmartPartInfo info1 = new ZoneSmartPartInfo(“CustomerNotes”); info1.Dock = DockStyle.Fill; ZoneSmartPartInfo info2 = new ZoneSmartPartInfo(“CustomerInfo”); info2.Dock = DockStyle.Fill; WorkItem.Workspaces[WorkspaceNames.CrmLayoutWorkspace].Show(WorkItem.Items.Get(“CustomerNotes”), info1); WorkItem.Workspaces[WorkspaceNames.CrmLayoutWorkspace].Show(WorkItem.Items.Get(“CustomerInfo”), info2);}

 

 

The last week someone posted this question to the CAB messageboard

    … there is any difficulty in combining other toolsets with CAB? where toolset = (DevExpress, Janus, ComponentOne, etc.)

This is a common question and I wanted to post the answer here as well so I could reference in the future.

CAB has many features: the EventBroker, the concept of a WorkItem,
SmartParts, Services, and more. All of them could be used without implementing
the toolset for CAB.
Besides, you have the UI or toolset-related part. I will separate it in 3 topics:

  • UI Elements/UI Extension Sites
  • Commands/CommandHandlers
  • Workspaces

UI Elements/UI Extension Sites

Another
feature CAB has is abstracting the UI elements (like menus, toolbars,
explorer bars, etc.). So you can treat them as just “sites” where you
can add new elements from any module. Let me clarify this. Think about
the Outlook Shell. When you switch between Mail, Calendars, Contacts
you have different toolbars and different menu items. You need a
mechanism to add/remove to these places.
That said, the Toolbar is
an “extension site” in terms of CAB, the ToolStripMenu is another, the
StatusBar is another, and so on. When the Mail “module” is activated, it will
add/remove what it needs to the extension sites.
If you want to add
UI elements to these sites using the CAB infrastructure you have to
implement the “Adapters”. These are very easy to implement. They are
just small wrappers of your controls with Add/Remove methods.

Commands/CommandHandlers

So
what happens when you click on a ToolsStripButton of the Toolbar? You
need to handle that click and do something with it. The Commands defeat
that purpose. If you are use to double click the toolstrip button in
the designer surface to create the event handler, then in CAB you won’t
have that facility.
From a module developer point of view you will add invokers to a ui element like this:

Commands["Reply"].AddInvoker(replyButtonItem, “Click”)

And then you will consume this event using a CommandHandler

[CommandHandler("Reply")]public void ReplyHandler(object sender, EventArgs e) {  ReplyMail();}

The
way to integrate this with your toolset is by implementing the
CommandAdapter. You will need one CommandAdapter for each specific UI element that raises a “Click” event
(e.g. ToolStripButton, the ExplorerBarItem, etc.)

Workspaces

Finally
you have workspaces. These are layout/containers. They will abstract
the addition/remotion/hiding of smartparts. That means that you will
add smartparts to a workspace and the workspace will wrap a layout
container. Eg. Tab Control, Deck Panels, Dock Panels, Zones, etc.
Implementing this, will let you change the visual layout of a set of smartparts with a minumum effort.

Next steps

Finally, you can learn how to implement these 3 elements by:
- looking at the CompositeUI.Winforms project
-
by downloading and looking over the CAB Extensibility kit of
Infragistics

- by looking at this article Dockable CAB Workspace

It’s been a long week here in Redmond. The workshop was really good showing
the latest patterns & practices stuff in the UX area: CAB and GAT
together.

I’m glad I was able to help during the labs and all of you
guys were really good working with CAB. The level of your questions was way too
much! :)

I had the opportunity to put some faces to my daily blogs (Brad Wilson, Peter Provost, Sam Gentile, Wojtek Kozaczynski, and more) and also talk
with very smart people.

I also met Andres
Aguiar
from Deklarit, Gabriel Lopez from Infocorp
and the guys from Clarius were also
there.

Andres, you still have to show me what you guys did with Deklarit and CAB! I hope that we will meet in a
place near Argentina or Uruguay the next time :)

These are some pictures I took

sc1

The lab full and the guys standing there are me, Juan Carlos

Elichirigoity and Wojtek

sc2

Eugenio did a great job this week and I finally endup doing the hardwork.

sc3

At the end of the day Ale Jack and me eating Pizza in… who knows where

sc4

Mariano Szklanny posted two great articles regards implementing a role-based approach to enable/disable CAB Commands. Check them out:

CAB - Adding Command-level security to
applications

CAB - CommandAuthorization AzMan Sample
Application