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.