e4 – A forward compat layer


In my last post I started explaining how one can write a so called forward compat layer for a custom application.

In the blog post I’ll present the first available bits of such a layer provided as part of the e4-Tooling effort. The idea of the forward compat layer is that you use the e4-Programming Model and write pure e4 POJOs which can be hosted inside an 3.x/4.0 workbench. Let’s at first look at the big picture how an e4-Application and 4.0 Workbench look like.

A pure e4-Application looks like this:

A 4.0 SDK with the backward layer like this:

An 3.x/4.0 SDK with Forward Compat Layer like this:

As the picture shows, the idea in the forward compat layer is to setup an DI-Container in a running 3.x Workbench and reusing the DI-Container provided in a 4.0-SDK Workbench.

Now that we know the background how can we work with it. The first thing to do is to write a Simple POJO which use an OSGi-Service of the type ITranslatorProvider:

package at.bestsolution.translate.view;

import javax.inject.Inject;
import org.eclipse.e4.core.di.annotations.Optional;

import org.eclipse.swt.widgets.Composite;
import at.bestsolution.translate.services.ITranslatorProvider;

public class TranslatorComponent {
  @Inject
  public TranslatorComponent(Composite parent) {
    createUI(parent);
  }

  @Inject
  void setTranslationProvider(@Optional ITranslatorProvider provider) {
    // Get the OSGi-Service injected    
  }
}

You should notice that the only “framework”-code we are depdending on is a bundle which defines the annotation we are using. Typically the components are kept in an extra bundle which has only dependencies on DI-Stuff.

If we want to integrate ourselves into a 3.x/4.0 SDK we somehow need to register our POJO in the DI-Container which is done in an e4-World by the ApplicationModel.

To register our View/EditorPOJO we are using specialized containers named DIViewPart/DIEditorPart like this:

public class TranslatorView extends DIViewPart<TranslatorComponent> {
   public TranslatorView() {
     super(TranslatorComponent.class);
   }
}

which itself is registered in the 3.x/4.0 Workbench using the views-extension point:

<?xml version="1.0" encoding="UTF-8"?>
<?eclipse version="3.4"?>
<plugin>
   <extension
         point="org.eclipse.ui.views">
      <category
            name="Utilities"
            id="at.bestsolution.translate.view">
      </category>
      <view
            name="Translator View"
            icon="icons/page_find.png"
            category="at.bestsolution.translate.view"
            class="at.bestsolution.translate.view.TranslatorView"
            id="at.bestsolution.translate.view.TranslatorView">
      </view>
   </extension>

</plugin>

The 3.x/4.0 integration is typically kept in a bundle which depends on the bundle with the component(s) and the standard set of 3.x plugins like (org.eclipse.ui, …).

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

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