Using the SAP Action and Menu Framework

This unit deals with the Action and Menu Framework with regard to its significance for tool integration within the SAP Java IDE. Using context menus as examples, we will illustrate how the action functions can be linked with UI components. Throughout this unit, we will be focusing on the Model Viewer (Generic Data Model Tree Viewer) as a UI component.

This document explains:

· What actions are and how you can implement your own actions

· The relationship between categories and actions

· How to inform the Eclipse framework about your own actions

· How to link a context menu with the Model Viewer

· Which relevant packages, classes, and interfaces you will use

· What essential parts the architecture consists of

Topics

Introduction

Understanding Actions

Understanding Categories

Understanding Action Management

Task 1: Creating Actions

Defining Context Menus

Task 2: Assigning a Context Menu to the Viewer

Example Plug-In

FAQ

Introduction

The SAP Action and Menu Framework was created with the goal of providing an independent action concept for the internal requirements of tool integration within the SAP Java IDE. The components involved (that is actions, path providers, or menus) are here generally implemented independently of one another and hence allow a clear separation between the actual action functions and their visual representation. A special feature of the SAP framework is the support of generic UI programming on the basis of the Selena Model API. In particular, this means that actions can be associated with Selena elements, as well as the usual SWT/JFace objects such as buttons, menu items, or toolbar items.

General Architecture

The following graphic shows the essential parts of the Action and Menu Framework architecture and illustrates their interaction at runtime.

You can generally link actions with any buttons, menu items, or toolbar items.

Within the Action and Menu Framework, the context menu participant represents the UI component with which a context menu is linked. Typically, predefined participants are used, including the Model Viewer in particular, but also other structure-oriented viewers such as the Tree Viewer, the Table Viewer, or even a list. In the case of a Model Viewer, the context menus are connected using the individual viewer elements. Here, the individual element is included in a tree structure and represents, for example, a specific object type. Depending on which elements were selected by the user, an appropriate context is provided for the generation of the corresponding menu (1).

The entries in a context menu can be defined statically, and hence predefined, while in the dynamic case, entries are not generated until runtime. For the dynamic context menu, an action is requested for the execution of an operation at runtime and assigned to the context menu.

Actions are requested at runtime using an action provider (2). All action providers are managed by the action provider manager.

The action provider decides which actions for a specified set of elements (action context) are passed to the system environment and returns the references to the actions (3). These references are linked to the context menu using the action provider manager.

To be able to associate an action with a UI component, the reference to an action is required as well as the information for a path. This path information then serves as a specification at which point in the UI an action is to be available.

This is where path providers become involved. Path providers are able to provide the path information from a specific action category (4), (5).

All path providers are managed by the path provider manager. The path provider manager is used to link the relevant path information with the context menu at runtime.

From the context and path information the menu factory then creates a type of “abstract context menu” that consists purely of context menu data (6).

This context menu data is converted into a visual representation using the menu engine. The engine creates the corresponding SWT/JFace UI component as a visualized context menu from context menu data (7).

On the other hand, for static context menus, all context menu data is already predefined at runtime and the process is reduced to steps (1), (6), (7).

If the user triggers an action within the UI component, the corresponding run method is called and used, for example, to manipulate the selected elements, start a new editor, or call a wizard.