major
nice-to-have
defect
major
enhancement
(User-visible)
It may be useful to define conditions that restrict the deletability of objects. Currently, such conditions can be implemented in specific domain object classes; see com.top_logic.element.structured.StructuredElement.allowsRemove().
This API is nonsensical because it is not taken into account in all call paths that lead to an object deletion. Furthermore, a build-time business object class is required.
Improvement
A deletion constraint can be defined on the business object type using the `delete-constraints` annotation. See com.top_logic.model.annotate.persistency.TLDeleteConstraints. The constraint itself can be defined either by implementing
#!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);
}
or configured via a TL-Script expression:
#!xml
<class name="P">
<annotations>
<delete-constraints>
<delete-constraint expr="x->if($x.get(`DemoTypes:P#protected`), #('Object protected.'@de, 'Object protected.'@en))"/>
</delete-constraints>
</annotations>
...
</class>
Delete constraints are inherited from property types, unless the inheritance is overridden using <delete-constraints override="true">...</...>.
Code Migration
If the method `boolean StructuredElement.allowDelete() ` is overridden in a domain class, either a deletion constraint must be configured on the model element instead, or the method `Optional<ResKey> TLObject.tDeleteVeto() ` must be implemented. In both cases, a reason must be returned explaining why deletion is not possible.
Test
- /com.top_logic.demo/src/test/com/top_logic/demo/scripted/model/type/TestDeleteConstraint.script.xml