Improve EMF.Edit integration

A problem with the current EMF.Edit integration occurs when an object is deleted. When the view gets notified it calls EMFEditUtil.removeListener(...). However, this method will not be able to find the actual item provider to remove the view as a listener from.

The reason is that it cannot find the proper adapter factory, because AdapterFactoryRegistry uses an aspect to adapter factory mapping. Since the object was removed, it is not contained in the aspect (through the hierarchy) anymore. This leads to a new adapter factory being instantiated and removing the listener will have no effect.

In Eclipse the responsible UI classes have a reference to the adapter factory being used.

A workaround (or hack) could be this for the removeListener method, which goes through the objects listeners to get to the responsible item provider:

for (Adapter adapter : object.eAdapters()) {
    if (adapter instanceof IChangeNotifier) {
        IChangeNotifier changeNotifier = (IChangeNotifier) adapter;
        changeNotifier.removeListener(listener);
    }
}

Another "problem" is that every time the item provider is needed, the registry has to be queried first. Since this happens a lot it might be helpful to keep a reference to the adapter factory in the view, which can then be passed to all calls of EMFEditUtil. However, the handlers will need something like that too.

Alternatively, there could be some kind of EditSupport class that is able to do this and keep the information. Every UI class that currently implements INotifyChangedListener could instead implement an interface that extends that interface and define an additional method to get the edit support or the adapter factory, which would allow the handler to get it.

Comments (3)