-
Notifications
You must be signed in to change notification settings - Fork 4
Tailor the graphical editor to the limitations of the textual representation
The Papyrus Viewpoint determines which graphical elements appear in the palette (usually on the right side of the editor) and which elements are proposed in the mouseover menus. We use the Viewpoint Configuration to show only the elements graphically, we can represent in our textual model. To provide our own Cooperate Viewpoint, we have to use the org.eclipse.papyrus.infra.viewpoints.policy.custom extension point. We registered the file resource/CooperateModeling.configuration. In this XML-file we specified rules describing what we want to see in the editor and to which diagram types we want this rules to apply. The file also defines a Stakeholder but currently we are not concerned with this. The file can be edited with the Papyrus Viewpoints Configuration Model Editor.
The rules are listed under
Papyrus Configuration > Cooperate Viewpoint > Cooperate Viewpoint :: UML Class Diagram.
With
Palette: clazz.tool.* => deny and Assistant: * => deny
we disabled all elements, so we just have to list the ones we want to show.
For instance, to put the Comment back on the palette, we have to right click on Cooperate Viewpoint :: UML Class Diagram, then navigate to New Child > Pallette Rule, and then set the rules properties Element = clazz.tool.comment and Permit = true.
Generally the Viewpoint can be chosen by the users themself under Papyrus > Viewpoints Configuration. To set the Cooperate Viewpoint by default we use the registerCooperateConfiguration() method in the Activator of this plug-in.
A list of available items can be found in the Papyrus repository:
- assistant rules
- palette tools (choose your diagram type and look for the paletteconfiguration file in the model folder)
For further reference take a look at the Papyrus Guide.
The Property View shows and edits properties of the UML elements. The Papyrus Property View Context determines which properties are shown and how they are presented. We use our own Property View Context to show only properties, that can be represented in our textual model. To register our Context, we use the extension point org.eclipse.papyrus.infra.properties.contexts. We registered the XML-file resource/CooperateProperties.ctx, which also references the files in the resource/ui subdirectory. Users can also create their own Porperty View Context. In order to obtain an .ctx file to start of with, we originally cloned an existing context with the help of this mechanism. To do so, we have to open the View Menu of the Property View (the downwards arrow in the top right corner of the view) and click Customize Properties view. Then we select a Context that we want to modify, click Copy to Workspace... and enter a name for this Context. The relevant files can be found under <workspace>/.metadata/.plugins/org.eclipse.papyrus.views.properties/<name>.
The file can be edited with the Papyrus Properties View Editor. The file defines Tabs and Views. Our Context contains only one Tab and several Views. Each View has constraints, that decide whether the View applies to the selected element (and is shown) or not. Each View consist of Property Editors and Composites, that can be arranged in different Layouts. But as mentioned above, we only removed unnecessary Property Editors.
In order to set our Context as default, we use the enableCooperatePropertyContext() method in this plug-ins Activator. In this method we also have to disable all other contexts, because Papyrus shows the union of all Contexts.
See also the Papyrus Guide
To prevent the user from saving a diagram, that cannot be represented in out textual model, we use the EMF Validation Framework. We register our own contraints and intervene when the Papyrus Editor tries to save the diagram despite some violated constraints.
To register a new constraint, we use the org.eclipse.emf.validation.constraintProviders extension point. The class that implements the constraint must extend de.cooperateproject.modeling.graphical.papyrus.extensions.validation.CooperateConstraint to be able to prevent the save operation. CooperateConstraint extends org.eclipse.emf.validation.AbstractModelConstraint, which is required by the extension point.
The validateCooperateModel(IValidationContext ctx) method can obtain the validated EObject with ctx.getTarget() und returns an ISatus, normally with ctx.createSuccessStatus() or ctx.createFailureStatus(new Object[]{}). The objects that are passed to the latter method can be referenced in the <message> tag of the constraint with {<array index>}.
The content of the <message> tag is the text presented to the user in the Problems View and if applicable in a pop-up window and should describe to the user, where exactly the constraints are violated. The description tag contains the description, that the user sees in the Preferences > Model Validation > Constraints menu.
The most notable properties of constraint are severity and mode. If mode is Live, the constraint will be validated on every change in the model. In Batch mode, the constraint is only considered if the user explicitly validates the model and when the model is saved (the latter is only due to our custom save mechanism). Generally a Cooperate Constraint should be a Live constraints, so that the user gets immediate feedback if he violates some constraints. When in Live mode, the severity ERROR reverts any change, that violate the constraint. WARNING only shows a message dialog, informing the user about the violation. Note, that the mode affects the behaviour of the severity. But in any case, a failed constraint prevents that the model is saved.
The target of a constraint is a class. It must be in the namespace of the ConstraintProvider. Thus in our case a class in the http://www.eclipse.org/uml2/5.0.0/UML model. The constraint is only validated against instances of this class. This is a usefull mean to filter out irrelevant objects, and keep the constraint itself clean.
For other examples and further possibilities of customization, look at the Papyrus Customization Guide.
Modeling Environment
Tools