rcp html5,Eclipse RCP (Rich Client Platform) - Tutorial

At runtime the structure of an Eclipse application is described via an application model.

This model contains the parts of the application as individual model elements and their hierarchical relationship.

Some are visible to the user, for example, windows, parts (views and editors), menus, toolbars.

Other elements are not directly visible to the user, for example handlers, commands and key bindings.

Each model element has attributes which describe its current state, e.g. the size and the position of a window.

The application model also expresses the relationship of the model elements via a hierarchy.

If necessary, a model element contains links to Java classes or static resources.

For example, a part contains a link to the Java classes which is initialized if the part becomes visible.

The base of the application model is typically defined as a static file.

For RCP application this file is, by default, called Application.e4xmi and located in the main directory of the plug-in which defines the product extension.

The Eclipse IDE ships with its own base application file.

This file is read at application startup and is used to construct the initial application model.

Changes to the model are persisted and if a changed model is present the application is restored from this model the next time it is started.

The application model is extensible, e.g., other plug-ins can contribute to it via model processors and model fragments.

During startup the Eclipse framework parses the available information about the application model (Application.e4xmi, persisted user changes and model contributions).

It stores the available information and their hierarchy in Java objects during runtime.

These objects are called model objects and at runtime they represent the attributes from the model elements.

Also an Eclipse IDE runtime or an Eclipse RCP applications running in compatibility mode will add elements to this model based on 3.x API, like view contributons via plugin.xml.

Model elements can point to a class or to a static resource via a Uniform Resource Identifier (URI).

For this purpose Eclipse defines two URI patterns.

Eclipse instantiates the referred objects or resources in most cases lazily.

For example, the classes for a part are instantiated when the part gets visible.

The following table describes the support URI patterns.

The example assumes that the bundle is called test to have a short name.

Table 1. URI pattern for class and static file references

Pattern

Description

bundleclass://Bundle-SymbolicName/package.classname

Example:

bundleclass://test/test.parts.MySavePart

Identifier for a Java class.

It consists of the following parts: bundleclass:// is a fixed prefix.

Bundle-SymbolicName is defined in MANIFEST.MF file.

The Bundle-SymbolicName is followed by a '/' and the fully qualified classname.

platform:/plugin/Bundle-SymbolicName/path/filename.extension

Example:

platform:/plugin/com.example.plugin/icons/save_edit.gif

Used to identify resources.

Identifier for a resource in a plug-in.

platform:/plugin/ is a fixed prefix, followed by the Bundle-SymbolicName, followed by the path to the file and the filename.

For example a part, have a Class URI attribute which points to a Java class via the bundleclass:// URI.

This class provides the concrete implementation of the part.

An example for a static resource reference is the the Icon URI attribute of a part.

This attribute can point to an icon that is used for the part.

The following text gives an overview of the available model elements in the application model.

The application object is represented as an MApplication object at runtime and is the root of the application.

Eclipse applications consist of one or more windows, its model representation is an MWindow or the MTrimmedWindow object.

MTrimmedWindow can contain trimbars (which can hold toolbars).

Parts are user interface components which allow you to navigate and modify data, , its model representation is an MPart .

Parts can be stacked or positioned next to each other depending on the container into which they are dropped.

A part can have a drop-down menu, context menus and a toolbar.

Parts can be classified as views and editors.

Views is typically used to display and modify a set of data, like a tree of table of data elements.

If the view allows to change data, this change is typically directly applied to the underlying data structure without the need to save explicitly.

For example, the Project Explorer view in the Eclipse IDE allows you to browse a set of files.

If you rename a file via the Package Explorer view, the file name is directly changed on the file system.

Editors are typically used to modify a single data element.

To apply the changes made in an editor to the data structure, the user has to explicitly save the editor content.

For example, the Java editor is used to modify Java source files.

Changes to the source file are applied once the user selects the Save button.

A dirty editor tab is marked with an asterisk left to the name of the modified file.

Parts can be directly assigned to a window or a perspective.

They can also be grouped and arranged via stacks (Part Stack) or sash containers (Part Sash Container).

A part stack arranges its children similar to a browser.

Is contains a stack of parts and shows their headers while content of one part is displayed.

The user can switch to another part by selecting the corresponding tab.

A part sash container displays all its children at the same time either horizontally or vertically aligned.

The following screenshot shows a simple Eclipse application layout using two part sash container and three part stacks.

On the top of this layout there is a part sash container which contains another part sash container and one part stacks.

These two elements are displayed side by side.

The part sash container on the next level contains two part stacks.

The hierarchy is depicted in the following graphic.

You can use the Container Data attribute on a child of a part sash container to assign a layout weight.

This layout weight is interpreted as the relative space the corresponding child element should get assigned in the part sash container.

The setting is depicted in the following screenshot.

If you set the Container Data for one element, you must define it for all the other elements, too.

Otherwise the missing values are interpreted as very high and these

elements take up all available space.

TIP:The initial total of all the container data values is

maintained when elements in the sash are moved.

In order to allow fine grained/smooth dragging this total must be similar to the

screen resolution.

A too low value (i.e., 50 / 50) causes the part to be moved multiple pixels per sash unit, which the user will realize as a jerky movement.

Therefore, use a sufficient high value, e.g., 10000.

A perspective is an optional container for other part containers and parts.

It is presented by MPerspective objects, which must be placed in an MPerspectiveStack object.

Only one of the perspectives in a perspective stack and be activated an made visible.

It is possible have shared elements between perspectives.

For example, the Eclipse IDE uses perspectives to provide view arrangements appropriate for different tasks, like development or debugging.

Switching perspectives can be done via the EPartService service provided by the Eclipse platform.

The following table lists the types of the important model objects.

Table 2. Eclipse model elements

Model element

Description

MApplication

Describes the application object. All other model elements are contained in this object.

MAddon

A self-contained component typically without user interface.

It can register for events in the application life cycle and handle these events.

MWindow

Represents a window in your application.

MTrimmedWindow

Similar to MWindow but it allows containing toolbars for the windows (via the TrimBars model elements).

MPerspective

Represents a different layout of parts to be shown inside the window. Should be contained in a MPerspectiveStack.

MPart

Represents the model element part, e.g., a view or an editor.

MDirtyable

Property of MPart which can be injected. If set to true, this property informs the Eclipse platform that this Part contains unsaved data (is dirty).

In a handler you can query this property to provide a save possibility.

MPartDescriptor

MPartDescriptor is a template for new parts.

A new part based on this part descriptor can be created and shown via the Eclipse framework.

Snippets

Snippets can be used to pre-configure model parts which you want to create via your program.

You can use the Eclipse framework to clone such a snippet and use the result object to attach it to the application model at runtime.