Community
Participate
Working Groups
Our metamodel requires every instance of an IdentifiedElement subclass to have a non-null identifier/name, but this requires an explicit action from the specifier for every element. Not providing this id can have very bad consequences, see bug #507226. The VSM editor should create new elements with a default, non-null and unique (in the context of its parent element) identifier. If the specifier has a better name to set, it does not change anything for him (but see bug #431991 to make this easier). If the specifier does not care or forgets, at least we can avoid some trouble.
New Gerrit change created: https://git.eclipse.org/r/85836
The patch at https://git.eclipse.org/r/85836 should only be considered a rough draft. The final solution will have to avoid touching all the XXXItemProviderAdapters of all concerned classes. In addition, the default id set on a new element should not use the technical class name as in the patch. Instead of the EClass's name, we should use the same label as the one used for the menu, so that the result is consistent from the point of view of the user. The "_" separator should also be replaced by a plain space. For example, "Bordered Node 1" instead of "NodeMapping_1" that the current patch would produce.
Some pointers to possibly useful information: * https://akravets.blogspot.fr/2013/11/customizing-item-provider-adapter-in-emf.html * https://github.com/mbarbero/econ-na-2014-emf-edit/blob/master/org.eclipse.emf.examples.library.edit/src-man/org/eclipse/emf/examples/extlibrary/provider/decorator/DecoratorEXTLibraryItemProviderAdapterFactory.java * the "Provider Root Extends Class" GenModel paramter (to be found in the "Edit" section of a GenModel's top-level element).
This ticket should be handled simultaneously with https://bugs.eclipse.org/bugs/show_bug.cgi?id=511783 as the solution may be very similar.
I'm actually wondering whether we should replace these user-supplied ids by opaque UUIDs like we did for the aird parts in bug #531410. This would avoid bugging users to choose unique identifiers (the original point of this ticket) and also probably improve the "comparability" of VSMs with EMF Compare. The only drawback I see would be that we need some "unique but user-readable" label to present the VSM elements, both inside the editor itself and in the various dialogs/wizards where the specifier must select an element, and with UUIDs we would need to rely on the label, which may not be unique.
