Major
Nice to have
Bugfix
Major
It can be useful to store conditions that restrict the deletability of objects. Currently, such conditions can be coded on special subject object classes, cf. com.top_logic.element.structured.StructuredElement.allowsRemove().
This API is nonsensical because it is not included in all call paths that lead to object deletion. It also requires a build-time object class.
Improvement
A deletion constraint can be stored on the subject object type via the annotation delete-constraints. Cf. com.top_logic.model.annotate.persistency.TLDeleteConstraints. The constraint itself can either be deleted via an implementation of
#!java interface DeleteConstraint { /** * Checks whether the given object can be deleted. * * A deletion veto is signaled by returning a non-<code>null</code> {@link ResKey} describing * the reason why the given object cannot be deleted. * * @param obj * The object in question. * @return If the given object cannot be deleted, a reason why deletion is not possible, * {@link Optional#empty()} otherwise. */ Optional<ResKey> getDeleteVeto(TLObject obj); }
can be coded or configured via a TL script expression as well:
#!xml <class name="P"> <annotations> <delete-constraints> <delete-constraint expr="x->if($x.get(`DemoTypes:P#protected`), #('Object protected.'@en, 'Object protected.'@en))"/> </delete-constraints> </annotations> ... </class>
Delete constraints are inherited from operatypes, unless the inheritance is knocked out via <delete-constraints override="true">...</...>.
Code migration
If the boolean StructuredElement.allowDelete() method is overridden in a subject class, either a delete condition must be configured on the model element instead, or the Optional<ResKey> TLObject.tDeleteVeto() method must be implemented. In both cases, a reason must be returned as to why a deletion is not possible.
Test
- /com.top_logic.demo/src/test/com/top_logic/demo/scripted/model/type/TestDeleteConstraint.script.xml