| Need explanation about getBeforeDestroyElementCommand and getBeforeDestroyDependentsCommand [message #1833770] |
Fri, 23 October 2020 11:18  |
Eclipse User |
|
|
|
Hello,
I'm trying to manage deletion events in a Papyrus model (using a custom profile). I defined *.elementtypesconfiguration file and EditHelperAdvice classes to custom the behavior of these new types during their lifecycles.
After some time using the EditHelperAdvice classes, I can't figure out the good practices to use getBefore/AfterDestroyElementCommand() and getBefore/afterDestoryDependentsCommand()
I just made a small test on a stereotyped interface owning two stereotyped operations. The EditHelperAdvice class for the interface contains :
@Override
protected ICommand getBeforeDestroyElementCommand(final DestroyElementRequest request) {
EObject eObj = request.getElementToDestroy();
System.out.println("Detroy Element : " + eObj);
return super.getBeforeDestroyElementCommand(request);
}
@Override
protected ICommand getBeforeDestroyDependentsCommand(final DestroyDependentsRequest request) {
EObject eObj = request.getElementToDestroy();
System.out.println("Detroy Dependents : " + eObj);
return super.getBeforeDestroyDependentsCommand(request);
}
The EditHelperAdvice for the Operation contains :
@Override
protected ICommand getBeforeDestroyDependentsCommand(final DestroyDependentsRequest request) {
EObject eObj = request.getElementToDestroy();
System.out.println("Destroy Operation : " + eObj);
return super.getBeforeDestroyDependentsCommand(request);
}
When I delete the interface I get :
Detroy Element : OperationImpl@29c12fe4 (name: Operation1, ...
Destroy Operation : OperationImpl@29c12fe4 (name: Operation1, ...
Detroy Element : OperationImpl@31c67262 (name: Operation2, ...
Destroy Operation : OperationImpl@31c67262 (name: Operation2, ...
Detroy Dependents : InterfaceImpl@4a4ebf86 (name: I_Test, ...
I can't understand why :
- the method request.getElementToDestroy() in getBeforeDestroyDependentsCommand of the interface EditHelperAdvice return the Interface (identical question for the EditHelperAdvice of the operation)
- the method request.getElementToDestroy() in getBeforeDestroyElementCommand of the interface EditHelperAdvice return the the Operation.
Shouldn't it be the opposite?
Is there something wrong with my understanding of these methods? potentially in my settings? in the API?
Thanks for reading.
Regards.
Yoann.
|
|
|
| Re: Need explanation about getBeforeDestroyElementCommand and getBeforeDestroyDependentsCommand [message #1833777 is a reply to message #1833770] |
Fri, 23 October 2020 12:53  |
| Eclipse User |
|
|
|
Hi, Yoann,
There are two different things happening here: recursive destruction of the model sub-tree and destroy-dependents.
The operations are being destroyed because the GMF run-time, when destroying the interface, recursively destroys the entire sub-tree rooted at that interface from the bottom up. That is why you see that first, for each operation, the interface that owns it is asked for destroy advice and also the operation itself is asked for destroy-dependents advice. Only after the sub-tree is processed (here being only the operations), then the interface edit-helper is asked for advice to destroy its dependents.
What you don't see is the edit-helper for the interface's owner (maybe a package) being asked for advice in destruction of the interface, because I guess you didn't put printfs in that.
So, I think that perhaps what was confusing you was that destruction proceeds recursively bottom-up and the owner of an element is asked how to destroy that element, not the element, itself. This aligns with the owner of an element being asked how to add a new owned element to itself.
It is worth mentioning, perhaps, that the sub-tree of the object being destroyed are all implicitly (structural) dependents and so don't need to be covered by the destroy-dependents advice. It is primarily intended for objects related "side-ways" in the model by arbitrarily complex means.
HTH,
Christian
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.42218 seconds
Home