Bugzilla – Full Text Bug Listing
| Summary: | [General] Application reacts different ways when trying to modify a read-only resource | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Vincent Hémery <vincent.hemery> |
| Component: | Core | Assignee: | Project Inbox <mdt-papyrus-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | cletavernier, give.a.damus, mathieu.velten, raphael.faudou, toni.siljamaki |
| Version: | 0.10.0 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 350910 | ||
| Bug Blocks: | 323802, 357254 | ||
|
Description
Vincent Hémery
The solution we preconize is to always run operations on the same command stack (instance of org.eclipse.emf.workspace.impl.WorkspaceCommandStackImpl). To achieve this, we should create a DiagramCommandStack which acts like a proxy to the WorkspaceCommandStack. Then, this proxy command stack would be installed on editors' graphical edit domains thanks to the org.eclipse.gmf.runtime.diagram.ui.parts.DiagramEditor.configureDiagramEditDomain() method. (overriding method in org.eclipse.papyrus.diagram.common.part.UmlGmfDiagramEditor and in org.eclipse.papyrus.sysml.diagram.parametric.part.SysmlDiagramEditor) This way, the default diagram command stack is bypassed and all executions are redirected to the WorkspaceCommandStackImpl, which itself delegates it to the operation history. Hence, users can still execute a command with any command stack or edit(ing) domain they currently use, but behavior and necessary checks are done in every case. About the lock checks which were performed by the DiagramCommandStack : They will now be performed by a proxy history, which is installed on the workspace command stack. The proxy history provides a way to contribute OperationApprover as the default history, but you can manage the order of the approvers using priorities. Hence, this proxy history performs all necessary checks regarding read-only resources (that all 3 needed resources are writable, that read-only mode is not active...), then either : - rises an understandable error message and forbides the modification - execute the correct modification on default history. With such an extensible mechanism, we will then be able to fully control when a modification is authorized and what the user is told. For the developper, all these mechanisms are compatible with all way of using a command stack or editing domain. Hence, no further code modification is needed on these usage. The only forbidden usage will be the direct execution on default history (not to bypass checks performed by proxy history) : OperationHistoryFactory.getOperationHistory() should no longer be used. work commited on branch, will be ported to trunk tomorrow. some public documentation is missing (schema and interface), this will be added tomorrow too. the proxy causes problems : post-commit actions needed to create the edit part after a modification of the notation model are called only at the end of the execute of a composite command instead of at each execution of command. This causes problem with commands that rely on the fact that the edit part are already created when reaching the end of the composite command (CommonDeferredCreateConnectionViewCommand for example). To fix that I removed the proxy and simply override getOperationHistory of DiagramCommandStack instead : CheckedOperationHistory is hence used. I also plug a correct CommandStack which use the OperationHistory on the abstract nat table editor. Still not backported on trunk, will be done in a few days. What is the status of this bug? The last comment indicating activity was in 2011 and I see that the CheckedDiagramCommandStack is long since in use on the master branch. Is it complete? It turns out that the ReadOnlyOneFileApprover, which I am working on in a branch for the dependent bug 323802, has been dormant ever since the org.eclipse.papyrus.commands plug-in was renamed as org.eclipse.papyrus.infra.gmfdiag.commands because the CheckedOperationHistory was still trying to load operation approvers from its extension point using the org.eclipse.papyrus.commands namespace. Therefore, no approvers are ever found. I have fixed this in commit b0b8ee5. Has this one been fixed = can be closed? > Has this one been fixed = can be closed?
No. The read-only mode implementation is not fully complete yet.
Fixed (See Bug 323802) |