Bug 430631

Description Michael Vorburger 2014-03-18 14:58:20 EDT

As briefly discussed with Ed (EMF), Eike (CDO) and Cédric (Sirius) during a break at EclipseCon today:

Currently, an EReference in a Properties view of an EMF Tree Editor can be changed via that drop-down which shows all matching instances available in the editor's ResourceSet (AFAIK).

This does not scale, on two dimensions: 1. non-functionally because everything has to be loaded in-memory, 2. functionally because the UX from a (non-searchable) drop-down UI widget is impractical in real-life.

In the Xtext-based ESON (see bug 425671), this is addressed & working better by having a [...] button which opens the Xtext XtextEObjectSearchDialog (AKA menu Navigate > Open Model Element), enabling an end-user to "pick" a suitable instance.

This Enhancement issue proposes that EMF make this UI properly and cleanly pluggable, including the necessary infrastructure non-UI API required for this.

Specifically, it would seem that some sort of Xtext-inspired IScopeProvider/IScope kind of API in core EMF would be valuable?  Independent of Xtext itself, of course (Eclipse layering).  Maybe something like this (not thought through, just a first idea dump / Xtext-inspired cheap ;) copy/paste) :

Interface & method names not intended to offend Xtext origins, but honour them -  although in distinct packages, using the same name could cause confusion - what do you guys want to name the new core one, proposed Core* prefix just a thought, better proposals sought:

A http://download.eclipse.org/modeling/tmf/xtext/javadoc/2.5/org/eclipse/xtext/scoping/IScopeProvider.html like org.eclipse.emf.scoping.ICoreScopeProvider, with a method ICoreScope (?) getScope(org.eclipse.emf.ecore.EObject context, org.eclipse.emf.ecore.EReference reference)

A http://download.eclipse.org/modeling/tmf/xtext/javadoc/2.5/org/eclipse/xtext/scoping/IScope.html like org.eclipse.emf.scoping.ICoreScope with an Iterable<CoreIEObjectDescription> getAllElements().  In order to build scalable UIs, how about also having a long getAllElementsSize().  To be able to provide filtering in an implementation, and not just the client of the API, how about also having options to search names, with options for startsWith, endsWith, contains, and case sensitivity - exposed probably with some neat Builder pattern.

A http://download.eclipse.org/modeling/tmf/xtext/javadoc/2.5/org/eclipse/xtext/resource/IEObjectDescription.html inspired but simpler org.eclipse.emf.scoping.CoreEObjectDescription with EObject getEObjectOrProxy() and String getName().  

It must be possible for an end-user to plug extensions to implementations of this API.  For example, in an in-house use of the Xtext-based implementation, you may subclass the CoreEObjectDescription and add a getSomeOtherAttributeThanJustTheOneAndOnlySingleName() - the custom implementation would fill this in from a getUserData(java.lang.String key) from the underlying Xtext's IEObjectDescription.  Other non-Xtext implementations of this new core API might have similar needs.

QualifiedName concept from Xtext deliberately dropped from this proposal - as I'd imagine that as a user of such an API, e.g. an object picker UI, you'd typically want to "show names" - it won't actually care how they were created (IQualifiedNameProvider & IQualifiedNameConverter infrastructure).  The Xtext-based implementation which would plug into such an Extension Point made available by core EMF would, obviously, use the appropriate IQualifiedNameConverter.

I appreciate that some implementers of such an API (e.g. CDO; I heard you outside during our chat Eike) may not (always) be able to provide a "name" for an object - they could just.. use some fallback (toString it).  Or we could keep the Scope  getEObjectOrProxy() and the getName() concepts further apart, with separate interfaces somehow - concrete counter proposals here more than welcome.  Personally I think having this as proposed above, as in Xtext, best matches how one would typically use such an API.

Implementation must be able to do a "lazy" implementation for scalability - all of the objects incl. the ultimate String name should only be created when actually used.

You would also need some general mechanism to look up the (one and only?) ScopeProvider.. probably not tied to Guice or e4 @Inject - preferably not a static Singleton.. you guys with significant experience on past and will know better than me how to do this right?  Just a kind of helper ScopeProviderProvider, with a static IProviderProvider getScopeProvider(org.eclipse.emf.ecore.EObject context or URI forResource), which would look up the appropriate implementation from an extension point?

I'd imagine that, separately from the non-UI new infrastructure API proposed above, something like the Xtext http://git.eclipse.org/c/tmf/org.eclipse.xtext.git/plain/plugins/org.eclipse.xtext.ui/src/org/eclipse/xtext/ui/search/XtextEObjectSearchDialog.java would want to find it's way into an EMF UI plug-in.  Implementation slightly adapted to have the size calculation and filtering delegating to the back-end implementation of the API, instead of happening in the UI.

A slightly different approach to what's being discussed here would be to not have a generic Scope infrastructure in EMF core (yet), but just an extension point to plug-in a generic "Picker UI", replacing the default drop-down.  This would probably be simpler; maybe could be a first step.

The concrete expected goal of this bug is (only) the Core EMF extension story; later follow-on bugs would be created e.g. for: 1. having Xtext hook into such a new extension point,  2. having EFactoryWithTreeEditor much simplified in ESON.

Projects such as ESON should then be able to significantly reduce code in https://github.com/vorburger/efactory/blob/1b09afbb9ab85762b412396b818463d3b4d61fe0/org.eclipse.emf.eson.ui/src/org/eclipse/emf/eson/ui/editor/tree/EFactoryWithTreeEditor.java  (Sirius may be able to profit from this as well?)

What do you guys think? Better counter proposals / amendments obviously most welcome. -- Would there be any interest in a proposed contribution for further discussion for something like this?