Community
Participate
Working Groups
I have a model in which the item providers do not provide executable remove commands in some cases (there are conditions on when an object may be removed from a certain container). The default DeleteService implementation contradicts the model's edit providers by just going ahead to force deletion of an object even when the editing domain does not provide an executable delete command. The delete service should respect the model's edit providers and only attempt deletion without a command in the case that there is no editing domain.
New Gerrit change created: https://git.eclipse.org/r/151632
Gerrit change https://git.eclipse.org/r/151632 was merged to [develop]. Commit: http://git.eclipse.org/c/emfclient/org.eclipse.emf.ecp.core.git/commit/?id=3ac69b52d43418160870f6a19d174a1794fb3a15
(In reply to Eclipse Genie from comment #2) > Gerrit change https://git.eclipse.org/r/151632 was merged to [develop]. ## TESTING INFORMATION ### Summary of the critical part of the change The default implementation of the DeleteService protocol now implements a new optional ConditionalDeleteService protocol that can tell clients whether objects can be deleted or not (according to enablement of the commands provided by the EditingDomain). For clients that don't care to check, it still will forcibly delete objects for which EMF.Edit provides unexecutable commands. But a few EMF Forms components do now check and disable their delete functions where applicable. ### Potential regressions Regression may occur in UI applications that previously assumed or required that the delete action was always enabled, where now it may not be if the model's edit providers don't offer executable deletion commands. ### Affected areas / use cases - delete action in the context menu of the tree rendered by the TreeMasterDetailSWTRenderer - delete button in the action bar of tables rendered by TableControlSWTRenderer and its subclasses (e.g. for Grid) - delete button in the link control rendered by the MultiReferenceSWTRenderer The TreeMasterDetailComposite used by the GenericEditor is not affected, as in fact it was already relying on the command provided by the editing domain to enable or disable the Delete action. So it was already correct but not in agreement with other UI elements. ### Things that shall be tested Deletion of objects in editors that use tables or the multi-reference link control to present contained objects: - that root objects (having no containers) now correctly disable the UI (they could not be deleted before, but the UI didn't indicate that) - that contained objects still can be deleted if their EMF.Edit providers allow it - that the delete buttons are disabled for objects that are not permitted by their EMF.Editor providers to be deleted (there may not be examples of this in the ECP project's test models)
Verified in the 1.23 integration build 1230_201910281527.
