Community
Participate
Working Groups
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?
I see at least 3 things, feel free to comment or contradict me : a) The EMF runtime should be able to display elements returned from the getChoiceOfValues calls which are actually not in the ResourceSet yet and we should have the ability to trigger some logic when they are getting picked by the ned user which, for instance, will include them on the resourceset. For this to be relevant to the generic technologies like Sirius this should not be overridable only through customization of the code generated for each Ecore model. b) a Scope/ScopeProvider API in EMF Core itself to do just that would help in making sure all the EcoSystem leverage these mechanisms "by default". c) a nicer UI to pick elements when there are many would be a cool addition to EMF.edit.
In https://bugs.eclipse.org/bugs/show_bug.cgi?id=438123 I've provided a clean mechanism for contributing a property editor factory. There's an example implementation in the wiki https://wiki.eclipse.org/EMF/Recipes#Recipe:_Create_a_property_editor_factory_to_use_declaratively_in_any_model There's also a built-in implementation to exploit Nebula CDateTime: https://wiki.eclipse.org/EMF/Recipes#Recipe:_Use_Nebula-based_Cell_Editors_to_Modify_Date.2FTime_Properties With this support you can build any UI and use it on any model. The property editor factory need not rely on the choices provided by the property descriptor; it can compute its own information however it likes. *** This bug has been marked as a duplicate of bug 438123 ***
