Community
Participate
Working Groups
We currently have at least three implementations of a master-detail renderer (SWTTable, GridTable and TreeMasterDetail). They all consist of the same core features: - create a master/detail composite, defining where the master and detail parts should be rendered - add some listeners to the master object to update the detail part accordingly - some housekeeping code (i.e. disposal of expired detail parts) This effectively results in a lot of duplicated code as those implementations share the same functionality. I suggest to pull-out the master-detail code into a stand-alone/common bundle and only leave the creation of the composite to the actual renderer implementations.
New Gerrit change created: https://git.eclipse.org/r/112566
Technically, this also affects the category renderer.
With this refactoring, we should also homogenize the detail view selection. In case of the tree master-detail, we already support a "detail" key which marks a view applicable to detail parts only. This functionality is missing i.e. for the table master-detail, where it is plausible that the user wants to display a modified view as part of the detail compared to the "default" view for the same type.
Also note, that master-detail can also be used recursively. Consider the following control hierarchy: Tree (view) -> Table (view) -> View (arbitrary) In this case, there is a master-detail relation between the tree view and the table view (tree master-detail). At the same time, the table view acts as the master component for its detail view (table master-detail). The table (view) therefore acts as a detail component and as a master component at the same time, bound by the selection.
New Gerrit change created: https://git.eclipse.org/r/142690
New Gerrit change created: https://git.eclipse.org/r/142764
Gerrit change https://git.eclipse.org/r/142764 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=e3a7e23fed6884922fb34456c5de13969c094628
Gerrit change https://git.eclipse.org/r/142690 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=21af1203ef471dd356f44d2f658ce85dac0bc5c5
The scope of this activity is reduced to factoring out the code that handles rendering of detail views with optional caching. The layout relationship between the master and detail panes is maintained in each renderer. ## TESTING INFORMATION ### Summary of the critical part of the change New API is provided in the org.eclipse.emf.ecp.ui.view.swt bundle for rendering of details in a master-detail UI: - DetailViewManager handles rendering and reuse of cached detail panes - DetailViewCache and BasicDetailViewCache provide caching strategies The TreeMasterDetailComposite, TreeMasterDetailSWTRenderer, TableControlSWTRenderer, and GridControlSWTRenderer all employ this new API to render their details and offer optional caching as specified either directly (in the case of the composite) or via a property in the view-model context (in the case of the renderers). The EcoreEditor that uses the TreeMasterDetailComposite now configures it for caching details. ### Potential regressions The new detail rendering implementation utilizes an in situ page-book (stacked layout) instead of re-parenting widgets into a hidden shell for management of multiple reusable detail renderings. So, complex layouts that embed the details composite (e.g. scroll composites) may see different behaviour in the sizing preferences of the details. EcoreEditor caches details where it did not before. If it depends on being able to render different instances of the same EClass in quite different ways, then that would be an issue. The ViewModelContext implementation had numerous problems in the handling of the lifecycle of child contexts, especially in changing their domain models (which is required for the reuse of a context with a rendered detail UI). Similarly the ValidationService and settings-to-control mapping service implementations. All detail views now present a hint that there is no selection of there is no detail to show instead of just showing nothing when there is no selection or when the selected object has nothing to edit. The TreeMasterDetailComposite customizes the message that is presented to match what it showed previously, but the message is no longer centred in the detail. ### Affected areas / use cases Master-detail renderings of all kinds. Validation decorations generally but especially in master-detail. ### Things that shall be tested Editing and validation in Ecore editor, view model editor, and other presentations of master-detail UIs. Especially for accurate updating of validation decorations both in the detail pane and also propagated into the master view (tree or table). Be sure to test with and without caching configured in the view model context (except Ecore editor which configures caching for itself). Also propagation of validation problems into the Categorization tree in which the new detail management framework is not used but which relies on the control mapping service that is changed by this feature.
In further testing of my private client application, I found that when an editor showing a table with detail panel re-loaded with changes from disk (as when pulling from Git), an exception was thrown [1] that resulted in the table not updating the contents that it shows the details panel continuing to show details of a ghost object using a disposed child context. [1] IllegalStateException "The ViewModelContext is already disposed."
New Gerrit change created: https://git.eclipse.org/r/143468
Gerrit change https://git.eclipse.org/r/143468 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=c32438dc94b16742d1de1b143f99d6d051a382e3
(In reply to Eclipse Genie from comment #13) > Gerrit change https://git.eclipse.org/r/143468 was merged to [develop].
New Gerrit change created: https://git.eclipse.org/r/144091
Gerrit change https://git.eclipse.org/r/144091 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=a6b2a7c3148a03f3863400d0e9df0b644d7ef9ac
The fix is published in 1.22 M1a.
Git bisect shows that commit 21af120 for this enhancement causes a regression in the validation state of forms-based editors such as the View Model Editor (not the Viewmodel Editor that is based on the GenericEditor). In the View Model Editor, the validation problem decorations shown in the tree for an element shown can disappear and reappear as the selection changes. It isn't clear what the pattern is, although it does seem that the problem decoration in the tree is always shown when the object manifesting the problem(s) is selected in the tree, and its detail pane also shows the correct problem indications.
(In reply to Christian Damus from comment #18) > Git bisect shows that commit 21af120 for this enhancement causes a > regression in the validation state of forms-based editors such as the View > Model Editor (not the Viewmodel Editor that is based on the GenericEditor). The problem is that prior to the introduction of rendered detail caching, the child contexts used to render details of the objects selected in the tree were never disposed. They were created initially by the tree validation initiator and existed in perpetuity (or, at least, until their corresponding model elements were deleted). This changed with the rendered detail caching, which (especially when caching is not enabled) will actually dispose these child contexts when the rendered detail SWT composites are disposed.
Gerrit change https://git.eclipse.org/r/145734 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=877cf7ae013d812727353d68ef337785c3c4e3cf
(In reply to Eclipse Genie from comment #20) > Gerrit change https://git.eclipse.org/r/145734 was merged to [develop].
New Gerrit change created: https://git.eclipse.org/r/145973
Gerrit change https://git.eclipse.org/r/145973 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=5d06f985200d70533061fa1d5eb5baa0f8acf403
Fix published in 1.22 M2.
