HowTo: manage dynamic layouts using CAB
March 29th, 2006
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.
Having a DeckWorkspace will
allow showing/hiding different layouts efficiently. This snippet of code shows
how:
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:
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.
Let’s see some screenshot of this concept implemented with CAB and SC-BAT March CTP.
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);}
CAB - Presentation Layer Toolset
March 27th, 2006
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
SC-BAT patterns & practices workshop - Redmond, Microsoft
March 18th, 2006
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
The lab full and the guys standing there are me, Juan Carlos
Elichirigoity and Wojtek
Eugenio did a great job this week and I finally endup doing the hardwork.
At the end of the day Ale Jack and me eating Pizza in… who knows where
Role-based Authorization in CAB
March 16th, 2006
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