Olivier,

Comments below.

On 16/03/2012 2:02 AM, Olivier Labrosse wrote:

Hi,

Our EEF-based model editor has an EMF-specific issue: a custom item provider's getParent(Object) method cannot access its tree parent due to its adapterFactory being a different instance than that of the tree. I explain...

First, the code:

public Object getParent(Object object) {
    Object parent = super.getParent(object);
    if (parent == null || parent instanceof Foo) {
        return parent;
    }
      

This is in the customized item provider for a Foo. You're trying to avoid it returning a Bar as the parent..

Quote:

    CustomBarItemProvider provider = (CustomBarItemProvider)adapterFactory.adapt(parent, IEditingDomainItemProvider.class);
    return provider == null ? null : provider.getTransientFooCategoryItemProvider(((Foo)object).getFooCategory());
}
      

So here you're trying to get the statefull item provider for Bar...

Quote:

Foo is contained in Bar, but can also itself contain sub-Foos, hence the check for the parent being an instance of Foo. The CustomBarItemProvider is stateful and holds references to three TransientFooCategoryItemProvider instances which are returned by getChildren(Object). There's one transient per category of Foo, and each transient's getChildren(Object) method returns the respective Bar's Foos of the respective category.

I see. And these correctly return bar as the parent...

Quote:

Now the problem is, when I do a drag & drop operation on a Foo, somehow its item provider's adapterFactory is different than its Bar container's item provider's, so what I get is a new CustomBarItemProvider instance which doesn't hold any transient item providers yet, let alone Foo's parents.

You could set breakpoints to see why there is more than one factory instance...

Quote:

I tried finding out why the adapterFactory is a different instance but it appears to be like looking for a needle in a haystack.

Generally when you customize an item provider specifically for a view, you create a customized item provider adapter factory and use it to create them. I'm not sure if you're doing that...

Quote:

Can anyone help me figure out a solution to this problem?

Looking closely I think the issue is very subtle and has to do with composition of factories. Have a look at the generated XyzItemProviderAdapterFactories two specialized adapt methods.

@Override
public Adapter adapt(Notifier notifier, Object type)
{
  return super.adapt(notifier, this);
}

@Override
public Object adapt(Object object, Object type)
{
  if (isFactoryForType(type))
  {
    Object adapter = super.adapt(object, type);
    if (!(type instanceof Class<?>) || (((Class<?>)type).isInstance(adapter)))
    {
      return adapter;
    }
  }

  return null;
}
    

You see the first one replaces the type object with the factory itself as the key but your call is directly calling the second one:

CustomBarItemProvider provider = (CustomBarItemProvider)adapterFactory.adapt(parent, IEditingDomainItemProvider.class);
    

This approach will call the first form and will return the already-associated adapter or create one if necessary.

CustomBarItemProvider provider = (CustomBarItemProvider)adapterFactory.adapt((Notifier)parent, IEditingDomainItemProvider.class);
    

In general, when you're dealing with models from many packages, it's important you go back to the root adapter factory and consult with it.

(((ComposeableAdapterFactory)adapterFactory).getRootAdapterFactory()
    

So I expect this approach would also avoid the subtle misdelegation.

CustomBarItemProvider provider = (CustomBarItemProvider)(((ComposeableAdapterFactory)adapterFactory).getRootAdapterFactory().adapt(parent, IEditingDomainItemProvider.class);