Community
Participate
Working Groups
When a resource is read-only, it can be opened by Papyrus or loaded in a model as additional resource (like in the cases of Profiles and Sub-models). When a user tries to modify such a resource, the issue should always be the same. For the moment, different cases may happen : - command's execution is tried from the diagram stack, ex : rename from figure : A GEF-inherited dialog proposes the user to make the resource writable, or to take the SVN Lock if this case is applicable. In such a case, problem is that the lock is taken on one file only, and not all registered models (notation, di, uml). - command's execution is tried from the workspace stack, obtained from the transactional editing domain : The modification is not performed, but the user receives no warning message. - command is executed, ex : rename a model element in outline view : The modification is temporarily performed on the resource, though the resource itself is read-only. This modification will most probably be lost at file closure. All these cases should look the same way for the end user. Modifications must be forbidden if there is no lock, and at least print an understandable warning message, and eventually propose to take the lock on all directly impacted resources.
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)
