Bug 514682

Description Pierre-Charles David 2017-04-04 03:46:10 EDT

In the context of a Sirius session, and in particular in the aird editor introduced in bug #510040, we want to make it as easy as possible for end users to create concrete instances of any metamodel, even if no "EMF Exampls Wizard" has been generated for it.

The current idea (open to discussion) is to have a 3-pages generic wizard:
* Page #1: metamodel (or concrete type) selection
  * A search field where the end-user type (part of) a metamodel name/nsURI, or a concrete type (suitable to become the root of the new resrouce).
  * A dynamically update list of proposals, matching what the user types.
  * Note that the "nsURI" of the metamodels should not be visible (or at least not prominent) to the end-users, as it is a very technical detail. Two possible ideas (not exclusive) to present metamodels instead of their nsURI:
    * Use an EAnnotation (to be defined/standardized, with specific support in EcoreTools to define it) to associate user-oriented documentation to an EPackage. It could even be a piece of HTML to be rendered in the wizard (see for example org.eclipse.sirius.ui.tools.internal.viewpoint.ViewpointsSelectionGraphicalHandler which does something like this for Viewpoints).
    * Define an extension point to allow associating this kind of documentation to existing metamodels without needed to edit them to add the EAnnotation.
  * The wizard should take an EPackage.Registry as a parameter and not hard-code the use of the global EPackage.Regsitry.INSTANCE.
* Page #2: root type selection
  * Assuming in the first page the user selected an EPackage and not a concrete EClass, the second page allows the user to select the type of the element that will be at the root if the new resource.
  * All possible (instanciable) types should be available.
  * A good default should be pre-selected if possible: if there are any, propose one of the instantiable types which are not contained by any other type. If there are several, prefer the one(s) which a contained by the least number of other types. If there are none, select the first found.
  * Optionally support an EAnnotation (to be defined) that could mark EClasses as "good candidates for being a root element", and leverage that information if present (and add tooling support for the EAnnotation in Ecore Tools).
* Page #3: name and location of the file to create
  * As much as possible, pre-fill the wizard with valid choices (the project/folder selected by the user when the wizard was launched, a default file name which does not clash with existing files...).
  * This third page could be made optional in the worflow (allowing the end-used to "Finish" directly from page 2) and/or merged in the second page if the result is not too crowded.

Warning: we must make sure the wizard works for created new Xtext resources, which may have some specific constraints (e.g. the rules to detect possible root container type may be different, not all grammars allow for completely empty files to be serialized etc.)

Overall, the wizard will probably be contributed to Sirius (although Amalgam could be an option?), but the actual code should not have dependencies towards Sirius if possible. Instead it should offer an API flexible enough for Sirius to use it meaningfully in its context.