[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [mdt-papyrus.dev] [Papyrus] Element Edit Service for Papyrus
|
Hi All,
In order to start generalizing the use of the edit service in diagrams, Vincent has made some useful changes in the GMFGenExtension model and generation templates (https://bugs.eclipse.org/bugs/show_bug.cgi?id=324966). These changes are used to turn the current way of deleting element in diagrams into the use of a delete command provided by the edit service (see my previous mail).
The modification targets the ItemSemanticEditPolicy#getDestroyElementCommand() and should result in a deletion with the same behaviour as the deletion of an element from the model explorer (multi-view, multi-diagram managed).
This modification is currently optional, meaning that you can test the delete element from the model explorer before deciding to replace the generation for any desired node (EditPart) in the GMFGen model.
For this matter:
- update the codegen / gmfgenextension / def plug-ins
- add a "EditPart using edit service for delete" node in the Papyrus extension root node of your diagram
- specify the EditPart(s) that should use the edit service for delete
- and regenerate the diagram.
Best regards,
YT
-----Message d'origine-----
De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx] De la part de TANGUY Yann 176637
Envoyé : samedi 11 septembre 2010 08:39
À : mdt-papyrus.dev@xxxxxxxxxxx
Objet : [mdt-papyrus.dev] [Papyrus] Element Edit Service for Papyrus
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
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
