Community
Participate
Working Groups
When changing the name of an element through the properties view, the edit service is correctly called in method org.eclipse.papyrus.properties.runtime.controller.EMFTPropertyEditorController.updateModel(). This behavior is correct. On the other hand, when we use the direct edit or the rename action in the Model Explorer view, a direct rename is performed, without consulting the edit service. This reduces the extensibility and prevents external code from reacting at name modifications using the edit service. There may be other cases I am missing, please answer if you know one. Code modifications : - the org.eclipse.papyrus.uml.modelexplorer.actions.RenameNamedElementAction.createCommand(Collection<?>) method should be updated to use the edit service (not trivial since currently, name is known at command's execution only). - the org.eclipse.papyrus.diagram.*.parsers.AbstractParser.getModificationCommand(EObject, EAttribute, Object) method should be updated in the corresponding template and all diagrams shall be regenerated. New code would look like : /** * @generated */ protected ICommand getModificationCommand(EObject element, EAttribute feature, Object value) { value = getValidNewValue(feature, value); if(value instanceof InvalidValue) { return UnexecutableCommand.INSTANCE; } SetRequest request = new SetRequest(element, feature, value); org.eclipse.papyrus.service.edit.service.IElementEditService provider = org.eclipse.papyrus.service.edit.service.ElementEditServiceUtils.getCommandProvider(element); if(provider != null) { return provider.getEditCommand(request); } else { return new SetValueCommand(request); } }
I disagree :-). The edit service is just an helper that you could used if you want. It is not, and it should be not mandatory to use it to change a name or to perform an edit. Papyrus use an MVC approach, so you should be able to modify the model in anyway you want (as long as you modify it correctly). All code needing to be notified of a change should observe the model, and should not rely on the fact that a particular service or method is called. So there is no need to modify actual code.
> All code needing to be notified of a change should observe the model, and > should not rely on the fact that a particular service or method is called. > So there is no need to modify actual code. Though the problem is : what if this code also modifies the model for consistency (as chain effect) and should be undone when the previous model modification is undone ? The model listeners are called in post-commit process, so they can not execute a command properly regarding the transactional context. If we perform model modifications in a post-commit context, they will not be undone properly. > Papyrus use an MVC approach, so you should be able to modify the model in > anyway you want (as long as you modify it correctly). I agree, but external code may encapsulate UML/SysML models with other models depending on them. Hence, a UML model can be modified correctly (regarding UML) and make the overall model inconsistent (regardind the rules of the encapsulating model). My concrete (and real) example is : - An external element (based on Ecore metamodel) references a UML element. - The name of this element can be manually modified but most of the time it is based on the UML targeted element's name. - Hence, when the name on the targeted UML element is modified, we would like the name's string to be replaced in the external element's name. Do you have a solution to make subsequent (name) modifications on the enclosing model ? For this particuliar feature (name modification), a validator would probably do the trick, yet it wouldn't for chain deletion (if element is to be deleted after targeted UML element's deletion, the validator couldn't re-create the element after undo). I think a generic solution should be available for all kinds of chain modifications, and the edit service looked like the ultimate solution, at least for chain deletions. Moreover, I am worried about consistency in the Papyrus editor, and I feel quite unhappy with the fact that modifying the name through the properties view or through the model explorer or through the label parsers may have different effects. :-S
All current implementations rely on the Service Edit. I close this task
