Community
Participate
Working Groups
This task describes the centralized element edit service for Papyrus. Main objective: Provide a centralized Papyrus service that can provide various type of command for elements (Create, Delete, Set) Implementation: Fully based on GMF ExtensibleType framework which provide anything needed for this purpose. This framework offers the possibility to declare IElementTypes (referring to model metaclasses) in a common registry. These IElementTypes can build various edit command using EditHelper(s). These edit helper can be extended completed, shared between element... One problem is that this framework is more or less used (IElementType are declared, but the default EditHelper are modified) by the code generated with GMF tooling. In addition to the fact that the tooling makes lot of duplication in IElementTypes, it also override some edit command which sometimes rely on activated edit part to be created. This leads to different behavior for the same kind of command depending on where they are created (e.g. deleting lifeline may have different result depending if it is executed in the model explorer, the sequence diagram or communication diagram). From a semantic model aspect the behavior should be the same (deleting element differently in diagrams may lead to unpredictable result when the same element are used in several diagrams). The ExtensibleType framework will be used as the default implementation for Papyrus edit service (though it could perfectly be used without Papyrus). In order to avoid any undesired mix in IElementType declared by Papyrus service or generated by the GMF tooling for Papyrus diagrams, all access to the Edit service in Papyrus will require a shared IClientContext to be explicitely provided and every IElementType, Advices to be bound to this context. The GMF notation dependant advice is also bound to Papyrus IClientContext. This advice is in charge of the deletion of View (in Notation file) when model element referred by these views are deleted. As the notation file is loaded when the model is open, the deletion of an element with the Edit service should lead to a correct deletion of any representation of this element in any kind of diagram (whether diagrams are opened or not). Main access to the extensible type framework is wrapped by Papyrus classes that ensure that Papyrus IClientContext is explicitely set in Request. To get an edit command, GMF edit request are used. The edit helper for UML element can be customized (e.g. Deleting a Lifeline -> delete parts that covers the Lifeline). Not tested but, whereas the edit command should have same behavior on the model, the graphical behavior may requires different behavior depending on the kind of edited diagram, it should be possible to add diagram specific notation related edit action (similar to notation dependent advice).
r2670 : org.eclipse.papyrus.service.edit (added to svn) r2672 : org.eclipse.papyrus.uml.service.types (added to svn) r2674 : oep.modelexplorer (delete command based on Edit service added) r2675 : oep.properties.runtime (modified to use the Element Edit Service) r2676 : oep.uml.modelexplorer (creation command and handlers for UML) r2678 : oep.sysml.service.types (types from former oep.sysml.service.creation) r2680 : oep.sysml.modelexplorer (sysml creation handler moved from former oep.sysml.service.creation) The following plug-ins are deprecated : - org.eclipse.papyrus.service.creation, - org.eclipse.papyrus.uml.service.creation, - org.eclipse.papyrus.sysml.service.creation
To use the element edit service, get the service associated to an specific element an use the getEditCommand passing in parameter a request depending on the kind of command to retrieve. Usage example of the element edit service: - Get destroy element command IElementEditService provider = ElementEditServiceUtils.getCommandProvider(selectedEObject); // Warning : the service may be null is no IElementType matching the selectedEObject is bound to Papyrus IClientContext // Retrieve delete command from the Element Edit service DestroyElementRequest request = new DestroyElementRequest(selectedEObject, false); ICommand deleteCommand = provider.getEditCommand(request); - Get creation command IElementEditService provider = ElementEditServiceUtils.getCommandProvider(container); // Warning : the service may be null is no IElementType matching the container is bound to Papyrus IClientContext // Retrieve create command from the Element Edit service CreateElementRequest createRequest = new CreateElementRequest(container, getElementTypeToCreate()); ICommand createGMFCommand = provider.getEditCommand(createRequest);
r2682 : source formatting.
r2684 : Replacement of existing service.creation by the new plug-in listed in previous comment in the build.
r2900 : In oep.gmfgenExtension : add a child to the Papyrus Extension Root Node : EditPartUsingDeleteService This child allows to list the EditPart which use the DeleteService (like in th Papyrus Model Explorer) In oep.def : LinkItemSemanticEditPolicy, NodeItemSemanticEditPolicy and manifest.xml are modified in order to use the child EditPartUsingDeleteService With these changes, we can now choose the deleting method for the elements using the gmfgen
r2911 : The goal of this commit is to allow to define which links use the ReorientCommand provided by the Edit Service in the gmfgen. The plugin oep.gmfgenextension is modified : a new child for Papyrus Root Node Extension is added: EditPartUsingReorientService In this node, we list the Links using the EditService for the ReorientCommand. The templates in oep.def are modified to generate code using this new information. - manifest.xpt is modified - linkCommands.xpt is added
r2955 : - Generated comment added on getDestroyElementCommand (using EditService) - linkCommands.xpt fixed (erroneous switch / case generation)
r2988 : oep.sysml.service.types - Matcher added for Block - Binding pattern corrected The previous binding pattern included element types defined in the Parametric diagram (their prefix also starts by org.papyrus.sysml.*) which are generated and not supposed to be registered in the Element Edit Service. The new regular expression used in pattern excludes org.papyrus.sysml.diagram.* element types.
The following deprecated plug-ins were removed (in r2993) : - org.eclipse.papyrus.service.creation, - org.eclipse.papyrus.uml.service.creation, - org.eclipse.papyrus.sysml.service.creation
*** Bug 316754 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > r2988 : oep.sysml.service.types > > - Matcher added for Block > - Binding pattern corrected > > The previous binding pattern included element types defined in the Parametric > diagram (their prefix also starts by org.papyrus.sysml.*) which are generated > and not supposed to be registered in the Element Edit Service. > The new regular expression used in pattern excludes org.papyrus.sysml.diagram.* > element types. Regular expression corrected (in r2994).
In r3059: - The shared context was not passed during getContainedTypeEditServices
In r3523: - Regeneration (after r3520 update)
In r3526: - Fix : Model explorer delete command caused an exception in case the selection was null
In r3573: - The pattern for UML ElementTypes binding was incorrect (patch from V. Hemery)
In r3878 (0.8.0M4 Indigo): - DefaultHeditHelper systematic declaration removed element type declaration from plugin.xml. The metamodel inheritance is used, but still need to be very cautious in case multiple inheritance may lead to incorrect helper (ex: Model -> Package -> TemplateableElement -> Element tested first, the NamedElement Helper would not be used here is an Element Helper is defined). - Minor change in default names, they start with upper case except for Feature(s). - Create and Re-orient support for DirectedRelationship - DirectedRelationship deletion when source or target are deleted - DirectedRelationship view removed after re-orient (requires diagram regeneration) - Behavior created in BehavioredClassifier are now added as ownedBehavior (instead of NestedClassifier)
In r3880: - in oep.modelexplorer the delete command on multiple selection should now take into account the dependents to be deleted for each item in the selection.
(In reply to comment #17) > In r3880: > - in oep.modelexplorer the delete command on multiple selection should now take > into account the dependents to be deleted for each item in the selection. Current "delete from model" implementation when graphical element are selected has not been modified, it still rely on each graphical edit part delete command, which rely on element edit service, but currently the ItemSementicEditPolicy providing this command flush parameters in DestroyElementRequest which does not enable the reuse of this parameters to take previous delete dependents into account. The same implementation as in model explorer should probably be used here rather than relying in EditPart policy.
In r4013: - API extended to retrieve service provider from IElementType (IElementEditServiceProvider#getEditService()).
In r4093: - Incorrect declaration of Papyrus service (now use ServiceFactory) In r4094: - IElementEditServiceProvider::isKnownElementType() method added to state if an IElementType is declared in Papyrus shared context - IElementEditServiceProvider::getEditService(Object) with an IElementType used as parameter now returns null if the IElementType is not declared in Papyrus shared context.
In 4464 - Default Constraint specification initialization added. New ValueSpecification in Constraint are now added as constraint specification.
In r4473 - NLS support added. In r4474 - Configure command can now be contributed as request Parameter to easily set an EStructuralFeature on a newly created element. In r4475 - Activation of Configure command contributed in request parameters in UML service type.
In r4478 - Restriction on FlowSpecification Behavioral & StructuralFeatures (can not own Operation or Reception, and only FlowProperty ownedAttributes) - Restriction on ConstraintBlock Behavioral & StructuralFeatures (can only own Property and ConstraintProperty) - All property created in the context of a ConstraintBlock are now Composite
In r4542 - Support added for binary connectors create and re-orient commands.
In r4630 : dependency added in undocumented rev. (r4586 [Palette] Update palette dependencies) removed.
In r4733. - Creation restriction: - Port can only be created in an EncapsulatedClassifier - DirectedRelationship creation corrected - Generalization creation corrected - ClassCastExceptions fixed in several advices (during before set, the new value type was not tested) In r4734. - ClassCastExceptions fixed in several advices (during before set, the new value type was not tested) In r4735. - Trace (from Standard will be needed by Requirement Diagram) declaration - MultiplicityElement declaration (add default [1..1]) declaration - Dependencies fixed. In r4736 - 4737. - Refactor. - FlowPort and FlowProperty allowed types were incorrect (inverted)
In r4738. - Association support for UML and SysML associations.
In r4745. - Relationship link Creation and Re-orient fixes.
(In reply to comment #27) > In r4738. > - Association support for UML and SysML associations. Lots of specific modifications commands related to Association are not implemented yet (move property end, modify the type of a property end...).
Reduce restriction for Property creation inside a FlowSpecification: - must be a FlowProperty OR a sub-specializationType Done in r6161 (0.8.X).
(In reply to comment #30) > Reduce restriction for Property creation inside a FlowSpecification: > - must be a FlowProperty OR a sub-specializationType > > Done in r6161 (0.8.X). Merge in trunk r6253.
In 7421 (trunk 0.9.0): - Refactoring to wrap the use of some request parameters - Default multiplicity fix (should not be explicitely set)
In r7424 (trunk 0.9.0): - Declaration to use ServiceEdit on stereotype application (static impl. SysML, partial on Standard profile)
*** Bug 424305 has been marked as a duplicate of this bug. ***
