Community
Participate
Working Groups
The default Cannonical Edit policy ( org.eclipse.papyrus.infra.gmfdiag.canonical.editpolicy.PapyrusCanonicalEditPolicy) is transforming CreateViewRequest of semantic children into DropRequest. This may have important side effects. For instance in my case, in a composite structure, I want to "cannonically" display my Parts. Some parts are typed by a class having a classifier behavior. In that case, the internal behavior is dropped in my Part, and the default drop strategy for that situation is to change the type of my part with the dropped behavior... In my customization, I managed to solve locally my issue by overloading the default semanticChildrenStrategy, returning only the ports as semantic children to display, but not the right solution. What is the reason for using drop requests? Is it simply because is it the "shortest way" to create a view from a semantic element? If yes, I think it would be very useful to provide a clean very simple API to create a view from a semantic element, with only the element, the location and the diagram to provide.
The Papyrus specialization of the CanonicalEditPolicy was specifically designed to delegate to the diagrams' native drop policies because these are generated from the GMFGen to know what view(s) to create, but there isn't sufficient API for the CanonicalEditPolicy to have the same information. So, I plan to investigate: * possible changes in the code generation templates to provide API that both drop and canonical edit-policies can use to do their respective jobs * whether the Active Operations Framework (currently in prototype) can be employed to simplify canonical synchronization, or perhaps improve its flexibility or other dimensions
New Gerrit change created: https://git.eclipse.org/r/57805 WARNING: this patchset contains 7443 new lines of code and may require a Contribution Questionnaire (CQ) if the author is not a committer on the project. Please see:https://wiki.eclipse.org/Project_Management_Infrastructure/Creating_A_Contribution_Questionnaire
(In reply to Eclipse Genie from comment #2) > New Gerrit change created: https://git.eclipse.org/r/57805 This proposed solution fixes the problem of Canonical Edit Policy and the diagram-to-diagram synchronization framework relying on the Drop Edit Policy to create new views. All existing JUnit tests for these two subsystems still pass and ad hoc testing seems to show no regressions. Changes to core APIs to remove PapyrusCanonicalEditPolicy's dependence on the generated diagram drag-and-drop behavior: * extract the CommonDiagramDragDropEditPolicy's abstract API for information about diagram-specific visual IDs into a new service * update the canonical edit-policy and diagram-to-diagram synchronization infrastructure to use the new VisualTypeService to obtain information about the diagram's specific visual IDs to then let the view service create views without resorting to drop commands * update extensions of various canonical strategies in the UML diagrams to adapt to the new drop-free synchronization mechanism Update the Papyrus Diagram GMFGen extensions and code generation templates to add generation of the IVisualTypeProvider that plugs into the new VisualTypeService to support canonical synchronization and drag-and-drop. Includes regeneration of the GMFGen extension model using EMF's most recent templates, which result in minor changes to most model source files. Regenerate all UML diagrams to create and register the visual type provider extensions. Also update the BREE for diagrams to 1.8 because at least one of them requires Java 8 to compile properly. * Note that the interaction overview diagram uses a code generator that is not published on Eclipse.org, so I had to emulate the code generation step for this one * Note also that the SysML 1.1 diagrams likewise cannot be re-generated but, moreover, they do not implement the common pattern for Visual ID Registry, so they are not updated and will, therefore, probably not support canonical synchronization Deprecate the ICreationTargetStrategy extension API which was only needed to redirect drag-and-drop requests, but these are no longer employed in the canonical synchronization.
I have uploaded a brief demonstration (ca. 4½ minutes) of canonical synchronization of state machines under the new implementation in the attached Gerrit patch: http://youtu.be/6W502QbTrN0
I have added a design note for this work to the Gerrit review and also the wiki: https://wiki.eclipse.org/Papyrus/Neon_Work_Description/Improvements/Canonical_Edit_Policy
Gerrit change https://git.eclipse.org/r/57805 was merged to [master]. Commit: http://git.eclipse.org/c/papyrus/org.eclipse.papyrus.git/commit/?id=f8dedc59a0e9bc39beaa61b7a8c2cad1252c9438
> Gerrit change https://git.eclipse.org/r/57805 was merged to [master]. Fixed on Master (For Neon M4)
