Platform Architecture

The Moomba Workbench is modeled on Eclipse workbench concepts. It is structured around the concept of bundles (or plug-ins). Bundles are structured bundles of code and/or data that contribute functionality to the system. Functionality can be contributed in the form of code libraries, platform 'extensions', or even documentation. Bundles can define 'extension points', well-defined places where other plug-ins can add functionality.

The workbench is an OSGi bundle that looks for services that contribute to it. Most notably these services contribute to the perspectives, views, and action sets of the workbench.

UI Framework

UI Layout

Banner Area

The workbench has a banner area which consists of an image area (designed for branding of the application), a status area and a toolbar. The image is simply set within the workbench resource bundle. For example:

<style name="Logo" type="org.karora.cooee.ng.ImageIcon">
	<properties>
		<property name="icon" type="org.karora.cooee.app.ResourceImageReference">
			<resource-image-reference resource="org/karora/moomba/resource/image/logo.gif"/>
		</property>
	</properties>
</style>

The status area has not been implemented yet, but will probably be accessible via the IStatusLineManager interface modeled on the Eclipse workbench.

Actions can be added to the main toolbar by registering an IAction OSGi service (or by injecting an IAction into the SimpleActionSetRegistry bean in a non-OSGi environment).

Perspectives

A perspective is a visual container for a set of views. The views exist wholly within the perspective and are not shared. If two or more perspectives have the same view opened, they share the same instance of the view although its layout may differ in the perspectives. For perspectives in different Workbench windows, views are also not shared. A perspective is like a page within a book. It exists within a window along with any number of other perspectives and, like a page within a book, only one perspective is visible at any time. Perspectives are used in the XBio Platform to denote significantly different parts of the system.
A Perspective is added to the workbench by registering an IPerspectiveFactory OSGi service (or by injecting an IPerspectiveFactory into the SimplePerspectiveRegistry bean in a non-OSGi environment). Perspectives will appear in the workbench in the order that the plug-ins were started in.

View Parts

As mentioned above, the layout of a perspective (whether it has sub-perspectives or not) should consist of one view part to the left, and at least one view part to the right. In exceptional circumstances it may be necessary to have more than one view part in the left-hand layout folder, but this should normally be avoided.
The view part in the left-hand part of the page should be a 'controlling' view part, that is, it should be a view part that offers a way for the user to navigate through the page. The view parts on the right-hand side of the pane should generally be collected in a tab pane (i.e. a folder layout) and should be views that display data to the end user.

It is also possible for each view part to have a toolbar. The developer should avoid adding buttons to the view part itself and instead the developer should add ViewAction contributions to the view part. These actions will then be displayed as toolbar buttons in the toolbar region. This gives the user a common place for view part actions.
The following code is an example of how a view part can create view part actions.

// Create the action and initialise it
 Action myAction = new Action() {
    public void run() {
       // TODO Implement action
    }
 };
 myAction.setText("myActionText");
 myAction.setToolTipText("myActionTipText");

 // Obtain the toolbar manager for this view part and add the action
 IActionBars bars = getViewSite().getActionBars();
 IToolBarManager manager = bars.getToolBarManager();

 manager.add(myAction);

Class diagram

Workbench under the covers

The workbench provides an extensive set of classes and interfaces for building complex user interfaces. Fortunately you don't need to understand all of them to do something simple. We'll start by looking at some concepts that are exposed in the workbench user interface and their corresponding structure under the covers.

Workbench

We've been using the term workbench loosely to refer to "that window that opens when you start the platform." Let's drill down a little and look at some of the visual components that make up the workbench.

For the rest of this discussion, when we use the term workbench, we will be referring to the workbench window (IWorkbenchWindow). The workbench window is the top-level window in a workbench. It is the frame that holds the menu bar, tool bar, status line, short cut bar, and pages. In general, you don't need to program to the workbench window. You just want to know that it's there.

Note: You can open multiple workbench windows; however each workbench window is a self-contained world of views, so we'll just focus on a single workbench window.

From the user's point of view, a workbench contains views. There are a few other classes used to implement the workbench window.

Page

Inside the workbench window, you'll find one page (IWorkbenchPage) that in turn contains parts. Pages are an implementation mechanism for grouping parts. You typically don't need to program to the page, but you'll see it in the context of programming and debugging.

Perspectives

Perspectives provide an additional layer of organization inside the workbench page. A perspective defines an appropriate collection of views, their layout, and applicable actions for a given user task. Users can switch between perspectives as they move across tasks. From an implementation point of view, the user's active perspective controls which views are shown on the workbench page and their positions and sizes.

Views

Views are where we move beyond implementation details into some common plug-in programming.

• A view is typically used to navigate a hierarchy of information, or display properties. For example, the navigator view allows you to navigate the workspace hierarchy. The properties and outline views show information about an object. Any modifications that can be made in a view (such as changing a property value) are saved immediately.

You will be building your view or editor according to a common lifecycle.

• You implement a createPartControl method to create the Echo2 widgets that represent your visual component. You must determine which widgets to use and allocate any related UI resources needed to display your view.
• When your view is given focus, you'll receive a setFocus notification so that you can set the focus to the correct widget. (''to be implemented'')

Seem simple? It can be. That's the beauty of workbench views. They're just widget holders, and can be as simple or complex as you need them to be. Let's look at a simple hello world view.

package com.mypackage.helloworld;
 import org.karora.cooee.app.Column;
 import org.karora.cooee.app.Component;
 import org.karora.cooee.ng.LabelEx;
 import com.gbv.platform.workbench.ui.part.ViewPart;
 public class HelloWorldView extends ViewPart {
    Label label;
    public HelloWorldView() {
    }
    public void createPartControl(Composite parent) {
       Column content = new Column();
       label = new LabelEx("Hello World");
       content.add(label);
       parent.add(content);
    }
 }