[mdt-papyrus.dev] [Papyrus] Element Edit Service for Papyrus

["TANGUY Yann 176637" <Yann.TANGUY@xxxxxx>]

Hi everyone,
 
I have added a service model element edit in Papyrus (https://bugs.eclipse.org/bugs/show_bug.cgi?id=324966).
 
Nothing completely new here, this service is fully based on the GMF Runtime extensible type framework (itself partly used by GMF Tooling generated code). In order to avoid unpredictable interaction between IElementType registered in this service and those redundontly declared in each generated diagram, a specific IClientContext for Papyrus has been declared. The IElementType declared for UML element in Papyrus (oep.uml.service.types) are all bound to this specific context. As a result, any attempt to retrieve these IElementType from the registry requires the Papyrus shared IClientContext to be passed explicitly (and set in request for a correct command construction).
 
This use of Papyrus specific client context is masked in oep.service.edit utility class and wrapper. In particular IElementEditService is a wrapper for IElementType which set the shared IClientContext in request before trying to get any edit command from the IElementType. ElementEditServiceUtils provide method to get access to the edit service of an element. Currently, this service is used in oep.uml.modelexplorer in the command handlers used to create new UML children of an element : 
 
e.g.
CreateElementRequest createRequest = new CreateElementRequest(container, getElementTypeToCreate());

ICommand createGMFCommand  = ElementEditServiceUtils.getCommandProvider(container).getEditCommand(createRequest);

"ElementEditServiceUtils.getCommandProvider(container)" return an IElementEditService (IElementType wrapper). In this case the return service can provide command to edit the "container" (EObject or EClass) passed in parameter. To effectively get and edit command, the getEditCommand is supposed to be called with an EditRequest which type depends on the desired kind of command to retrieve (see GMF EditRequest and sub classes).

This service is also used in  oep.modelexplorer to provide a replacement delete command in the model explorer contextual menu (the old version is kept for now - marked as deprecated). This command should work in multidiagram and with undo / redo. The command created when deleting an element, build a composed command by deleting any contained element in the tree (recursively), in addition to this, a specific edit helper advice bound to Papyrus IClientContext add notation specific command that delete each view that reference a model element to be deleted. Several representation of a single model element can then be correctly deleted (wheter they are on the same diagram, whether the diagrams are opened of not - view are deleted in notation model without requiring EditPart to be activated).

The code generation has not been modified yet to replace destroy command creation in generated semantic edit policies. I suggest that developpers in charge of diagrams test this delete command from the model explorer contextual menu and send feedback in sub-task of Bug_324966 (issues, improvement or specific deletion behavior request...) before generalizing the deployment of this command in the generated code.

Retrieving the delete command for an element can be done programmatically like this : 

IElementEditService provider = ElementEditServiceUtils.getCommandProvider(selectedEObject);

if(provider == null) {

continue;

}

// Retrieve delete command from the Element Edit service

DestroyElementRequest request = new DestroyElementRequest(selectedEObject, false);

ICommand deleteCommand = provider.getEditCommand(request);

 
The extensible type framework is highly customizable, and I guess that lot of command extension could be registered. But let's keep in mind that the changes made in oep.uml.service.types will have effect on any diagram (same behavior of command on the model, but it should be possible to register diagram specific notation edit customizations). To avoid having too many of us modifying edit commands with the risk of using different approaches, I ask you not to commit directly in oep.uml(sysml).service.types, but to provide patch or improvement requests under https://bugs.eclipse.org/bugs/show_bug.cgi?id=324966, I'll deal with the integration in the IElementType EditHelpers and Advices.
 
best regards,
 
Yann
 
______________________ 
CEA SACLAY DRT/LIST/DTSI/SOL/LISE 
91191 Gif sur Yvette FRANCE 
email : yann.tanguy@xxxxxx 
Tel : + 33 1 69 08 87 63 
Fax : + 33 1 69 08 20 82