major
nice-to-have
defect
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