In the process of creating the Expeditor Dashboard application for my team I wrote a component that has ended up being a good generic component that allows the wiring of different components directly from the runtime UI. I wrote a little about this early in the "Wire or not to Wire, and then whom?
" posting. The original purpose of the component was to drive the categorization of the Notes view directly below it. With the new capability in Notes 8.0.1 where you can use any
existing view and wire components to it; this makes for a perfect fit for my dashboard. I assembled a series of pages where each one has a single view with a category on it - the button navigator should give you a good idea for the views used. The new component then allows other components on the screen to drive the category selection
- in these screens they are all names. Here is a screen shot where we will talk about each of the actions in the component.
The component is very customizable in CAE - you can hide and show any or all buttons, you can show icons only, change the label of the buttons, and change the label "Requirements for:" to anything you want. This makes the component very re-usable for any categorized view. While I show all of them in the dashboard, you may want to limit what buttons are available to your end users.
Let's dive on what each button does.
The "Remove Filter" button simply does a property change of a "null" value, resulting in the wire category view to reset itself to no categorization.
The "History" button is a drop down list of categories you have recently used. This is good if your other "linked" components are now hidden in the side shelf and you want to select someone from the 10 most recently used categories.
The "Link" button is to allow selections from any
Eclipse based component to drive the category in the view. What this generic component does is listen for all workbench selections from these selection components and forwards the selection on using the property broker (in this case I want names from my Team Members view and the Sametime Contacts view). The end user can select what components drive the categorization. This is probably the most powerful feature. This is basically an Eclipse selection bridge for the property broker and all composite application components.
I also persist the users selections per page - this means once the selections are made they are save with this page and the user does not have to select them again. Actually, ALL of the buttons follow this serialization model. So any selections are all saved, including the History list.
The "Wire to" button does exactly the same thing as the Wiring capability in CAE. You can wire the category selection bridge component to any
compatible composite application component on the screen. This means if your screen had several views on it, the end user can select which ones will receive the property change. The "FilterCurrentUIViewViaCategory
" action is checked and disabled because this was "hard wired" in CAE. I really like this because if there is more than one view on the screen and everything is "hard wired" performance may suffer. This allows the end user to select which components they want updated when a selection change is made.
The "Map" button came after I found out that many people's names are different in applications. For instance, my name may appear as "Bob Balfe" in Sametime but might be "Robert Balfe" in the problem report system. What the map function does is when a selection of "Bob Balfe" comes in, it will forward on "Robert Balfe" if that map existed. You can add as many maps as you want using the "Edit mappings" option:
Lastly, the Click to Action or "C2A" allows the end user to immediately call an action on a compatible component. This is where you want a component to do something in real-time and not be wired persistently in the future. By calling the action directly, the last selection obtained is immediately forwarded on. Once again, a great model if for instance there were more than one view on the screen.
So in short, this component was designed to let the user choose how things interact on the screen. It also shows some pretty interesting patterns for how things can be wired, linked and serialized. Probably the best thing about these concepts are they can all be done today in Notes 8.0 and Expeditor 6.1. They use a combination of the Topology API's, the Property Broker API's and the Eclipse API's for workbench selections and views. I am looking to get the sample and code to be part of the Expeditor 6.1.2 and Notes 8.0.1 products - or at least in a web delivery.