In case you were wondering or struggling, just like me, how one could possibly load an Application.e4xmi file out of a standalone Java application, here goes some code for you 🙂

import org.eclipse.e4.ui.internal.workbench.E4XMIResourceFactory;
 import org.eclipse.e4.ui.model.application.MApplication;
 import org.eclipse.e4.ui.model.application.impl.ApplicationPackageImpl;
 import org.eclipse.emf.common.util.URI;
 import org.eclipse.emf.ecore.resource.Resource;
 import org.eclipse.emf.ecore.resource.ResourceSet;
 import org.eclipse.emf.ecore.resource.impl.ResourceSetImpl;

public class LoadAppModel {

private static ResourceSet resourceSet = new ResourceSetImpl();

public static void main(String[] args) {
 ApplicationPackageImpl.init();
 URI uri = URI
 .createURI("file:///Users/marco/git/pharmacy_at/at.medevit.ecrit.pharmacy_at.application/Application.e4xmi");

resourceSet.getResourceFactoryRegistry().getExtensionToFactoryMap()
 .put("e4xmi", new E4XMIResourceFactory());

Resource res = resourceSet.getResource(uri, true);
 MApplication app = (MApplication) res.getContents().get(0);
 System.out.println(app.getElementId());
 }
 }

res.unload();

Be sure to include all the required bundles, especially in the OSGI context.

Update I just came up to a nasty problem: If you repeatedly iterate your application model, while modifying it, you need to be sure to unload the model each time you are done, otherwise lazy loading will not pick up the changes, as the model is already loaded.

To depict this I added the unload method to the code sample.

I’ve been banging my head some time now (which can be seen in Bug 397249) on the problem of sychronizing stateful Eclipse 4 application model items with the code.

Wait, let me set the scene first: The Items I am talking about are either Direct or Handled, Menu or Tool, Items added to either a Menu or a Toolbar in the application model. And by stateful I mean the requirements of Items of type Check or Radio to have their state synchronized with the state of the application.

Statefullness requires a Command connection

Overall stateful usage of items is bound to being connected with a Command, hence all items of type Direct are generally not considered for stateful usage. They should be used with check type only, for one shot execution of whatever you might deem necessary.

I, however, see a feasible way to use them in Type.Check which might be handy to you. In order to update the state of a Type.CHECK Direct*Item, simply use the @CanExecute annotation for a method in your contribution_uri class like this:

@CanExecute
public boolean canExecute(MItem element) {
  element.setSelected(false);
  return true;
}

@CanExecute is called everytime your element is to be shown. It allows you to update the availability of your action according to your settings, and you may also use it to update the state.

Using Direct*Items is good for smaller tasks, but one must not forget, that using this element the model has to access the implementing class to query the state. This may lead to lazy plug-ins being started just to gather the information about the availability resp. state.

Stateful Handled*Item

In order to use Handled*Items, a method (not in the code meaning but literal) is required to initialize the state of your Type.CHECK and Type.RADIO items at startup to the state of your code.

Let’s consider this for both Type.CHECK and Type.RADIO. Lets fix an example of a viewer (yes, just like this SWT TableViewer example) showing a set of Persons being either male or female. A person may also be married, single or widowed.

The Type.CHECK items in the filter will be the boolean representation of showOnlyMale in Handler, which sets it into the state to show only male persons.

The Type.RADIO items will allow us to show married, single or all persons. Here we have three contribution items which together form a radio group.

It is important that the items allowing us to select the states will be present more than once but connected to the same command. The following image depicts this:

The code is implemented in the Handler part, while the model is being represented by all none code parts, that is the Command and the multiple ContributionItems.

One may set the isSelected feature of the Contribution items within the application model, they are, however, not being synced to the state of the Handler (i.e. the Filter in our example) and vice versa (how should they, Eclipse does not know about the connection).

So first the question arises, whether the model should synchronize to the code, or the code to the model for this cases?