Community
Participate
Working Groups
Current Behavior: The emfforms view model generator currently only creates controls for all features. This results in a MultiReferenceControl for containment and non containment references. Expected behavior: The more common requirement is to have a table for containment references as the user usually wants to directly edit attributes of contained objects. Implementation and possible regressions This will result in a dependencies of the view model generator to the table bundles. Also existing users which rely on the generator will have a different control and will need to create a dedicated view model to keep the old behavior.
Mass Move due to time constraints
Mass move to 1.20 due to time constraints.
New Gerrit change created: https://git.eclipse.org/r/133935
Gerrit change https://git.eclipse.org/r/133935 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=8c4ff27f5953b975b141601e49a5d5a53d075518
The view generator now generates table controls for multi containment references. As a consequence, by default an editable table is shown for multi containment references. Until now a simple list was shown. For all other cases the generation stays the same. TEST INFORMATION Summary of the critical part of the change The view generator now generates table controls instead of normal controls for multi containment references. Potential regressions If generated views with multi containment references are used, the view changes. The contained objects are now directly editable in the table. The table has a column for every attribute of contained objects. Affected areas / use cases Using auto generated views for EObjects that have multi containment references. Things that shall be tested That generated views still look as expected.
