Bug 482831

Description Pierre-Charles David 2015-11-23 07:38:29 EST

EMF.Edit has direct support for many operations which are also conceptually available in Sirius representations, for example ItemProvider.getText() to render an EObject as plain text, which is similar to Sirius's various 'Label Expressions'.

Sophisticated EMF users with complex metamodels tend to heavily customize the generated item providers, and expect these customizations to apply as transparently as possible in all EMF-powered applications, including Sirius. While it is possible right now to delegate to the ItemProvider from Sirius, it involves writing a lot of custom Java code in the form of services to invoke from interpreted expressions.

The goal is to make it easier (maybe even the default in some cases) for specifiers to use the behavior they have specified/customized in their ItemProviders directly from Sirius representations wherever it makes sense.

Note that an important conceptual difference between the two approaches is that the behavior ItemProviders usually only depends on the underlying EObject, and is fixed (i.e. the same EObject renders as the same text in all contexts, at least when using the same ItemProvider), while in Sirius the equivalent behavior can be highly context-dependent (the same semantic elements may render in completely different ways in different representations, or even in the same representation depending on this like which viewpoints or layers are enabled).

The precise list of "operations" to take into account is yet to be determined, and not all may be implemented in the first iteration.