e4 – Fundamental Overview on the Eclipse 4 Application Platform


In my last blog post I talked very short about the relation of XWT and the Eclipse 4 Application platform. It looks like many people are mixing things up. In this post I’ll try to give a deeper look into the Eclipse 4 Application Platform which might make even clearer why XWT is not necessarily part of a Eclipse 4 application.

I can only reiterate that the Eclipse 4.0 Application Platform (EAP) is not forcing you in a direction or technology (it even not force you to use SWT though for many applications this might be the natural choice). Let’s look at the big picture at first.

The center of an EAP-Application is the Application Model   is defined using Ecore and holds the complete application state at runtime. One of those runtime informations is the core UI-Structure your custom UI-Code is plugged in at runtime but there are many other none ui types found in like handlers and commands. You can think of the Application Model as the central registry of an EAP Application and because things come and go in a running application the model is dynamic and changes while your application is running (e.g. when switching Perspectives, moving UI-Elements around e.g. detaching an editor)

An interesting fact though is that you also use this very same Application Model at design time which is in complete contrast to Eclipse 3.x where you use the plugin.xml-Model to describe your application. The default format we use to persist the model at design time is XMI which is supported by EMF but in the end the EAP does not really care in which format the Application Model is persisted all it needs when starting up is an in memory instance of the model.

This means the Application Model has 2 different states in can be in:

  • Designtime state: Used to describe how the running application should look like when started which gets persisted e.g. to an XMI-File
  • Runtime state: An in memory model loaded e.g. from the designtime state stored which gets processed by EAP and once finished the Eclipse 4 Application UI is presented to the user and after this point a bidirectional relationships between the in memory model and UI-Controls is established

The 2 different states the Application Model can be in is also reflected by the tooling:

  • Model Editor: Is an filesystem based editor similar to the plugin.xml-Editor and stores the model as an XMI-File
  • Live Model Viewer/Editor: Is operating on the in memory model of an running EAP Application and because the model is a live model you can not only view informations but also modify them
    State 1: State 2:

Now let’s go on to see what the EAP does with the model and how it creates the UI out of this abstract information.

As outlined already the Application Model holds UI-Information but what you find in the model are abstract UI-Concepts like Window, Perspective and PartStack but does not talk about concrete widgets to used to implement such a concept in the UI presented to the user. The transformation (we call it rendering) of the model elements into concrete widgets is the responsibility of the Rendering Engine  .

From a very highlevel the process is like this:

The last small thing I’d like to show in this post how the Java-Class referenced in the MPart named my.bundle.a.View looks like:

package my.bundle.a;

public class View {
  @Inject
  public View(Composite parent) {
    // Make up the content displayed in the part
  }
}

There are a lot of talks at EclipseCon 2011 and I’m giving a tutorial together with Kai Tödter and Eric Moffatt where you can learn how to write applications using the Eclipse Application Platform.

Advertisements
This entry was posted in e4. Bookmark the permalink.

4 Responses to e4 – Fundamental Overview on the Eclipse 4 Application Platform

  1. David says:

    There are lots of people with RCP applications who I am sure, like me, would love to move across their existing editors, views etc. into e4 EAP. A clear focussed tutorial on how to do this will be of great benefit to us.

    To be able to have all Commands, Menus, layout etc. nicely abstracted in the EAP model and thus isolate your custom views is going to make maintenance of what are currently really quite complex RCP apps much easier.

    thx.

    David

    • Tom Schindl says:

      I’ll try to update my Tutorial e4 RCP Application tutorial when we ship 4.1 and if possible publish a tutorial on how to use parts of e4 even with 3.x (DI is one of those) but because I’m doing this in my spare time I can’t promise. I think the modeltooling is entering a state now that all major features I wanted to implement are in and I can once more work on other fundamental stuff.

  2. Oleg Buchhammer says:

    Hello Tom,

    Thank you for your great BLOG!!!

    What do you think about integration of RAP to eclipse SDK 4?

    Your comment is awaiting moderation.

    • Tom Schindl says:

      There are some problems when running RAP on the Eclipse 4 Application Platform. The most prominent is that one needs to replace the default IEventBroker through a RAP specific one because the default one uses the OSGi-EventAdmin which is a framework singleton and hence all RAP-Instances would communicate through the same channel.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s