EMF Compare/Specifications/CSShandlingForPapyrus

Evolution Specification: CSS handling for Papyrus

Current status is 'DRAFT

Preamble

CSS handling for Papyrus.

_Relevant tickets_ (links to the Bugzilla tickets which are related to the change):

• Bug 398367 - CSS handling for Papyrus

Introduction

Appearance in Papyrus diagram are handled through CSS style sheets which are only stored on “set” within the notation models. EMF Compare have to forbid the merge of CSS changes when they have not been “set” directly on the object.

Detailed Specification

Test protocol

Create profile with custom shape

• Create a UML profile model
• Create a stereotype (which extend an UML element for example a component)
• Select the UML property tab and add an icon using the + button
  • Give the icon a name
  • Set the kind to "shape"
  • Set the format to "SVG"
  • Set the location to of the SVG file (use platform:/resource/path_to_file for not integrated icon and platform:/plugin/path_to_file for integrated icon)
• Save and export the profile (Done wile saving)

Note: Following the documentation it should be possible to use relative path to the icon however in my tests it did not work.

| For more information

Apply the custom shape to your model

• Create UML model with stereotyped elements in it
• Create CSS file to apply the custom SVG shape on your stereotyped elements:
  • Create a new .css file
  • Use the following example to customize (This example customizes uml components with the stereotype "YOUR_STEREOTYE_NAME")

@charset "UTF-8";

Component[appliedStereotypes~="YOUR_STEREOTYE_NAME"] > Compartment[type="compartment_shape_display"]{
	visible:true;
	showTitle:false;
}

Component[appliedStereotypes~="YOUR_STEREOTYE_NAME"] > Compartment {
	visible:false;
}

Component[appliedStereotypes~="YOUR_STEREOTYE_NAME"] {
	maintainSymbolRatio:false;
	fillColor:white;
	displayBorder:false;
	displayName:false;
	followSVGSymbole:true;
}

• Apply it to your model using the following [1].

Test result

The tab shows you the result of a comparison between two papyrus models in a git repository. Each use case uses a different level of integrartion (Model, Workspace etc..) or a different type of profile. Every step of each test has been recorded in a git repository that you can download File:Emfcompare-papyruscss-git.zip. You can also the target platform here. To reproduce the comparison select the branch that is matching your use case and compare with previsous version. Please read carafully the history of the scenario that you want to reproduce .Some projects should be integrated to the platform and some other are projects holding models. For each use case a screenshot of the result has been taken to faster the read of the tab.

	Not integrated CSS				Integrated CSS	Embedded CSS
Level of integration	Workspace	Project	Model	Diagram	Workspace	Model
Dynamic profile not integrated	-	-	-	-	-	-
Dynamic profile integrated	-	-	-	-	-	-
Static profile (generated sources)	x (Profile not loaded)	x (Profile not loaded)	x (Profile not loaded)	x (Profile not loaded)	x (Profile not loaded)	x (Profile not loaded)

Backward Compatibility and Migration Paths

Metamodel Changes

TODO. (Document any change to the metamodel. If they require a migration operation, mention it and describe the general idea of how migration process. If any information can be lost during the migration, mention it clearly. If validation rules must be added/modified, mention it also.)

API Changes

TODO. (List every API addition, removal and deprecation. For each removal and deprecation, indicate the migration path for existing code.)

User Interface Changes

TODO. (List every user-visible change in the interface. Here "user" includes not only end-users but also developpers.)

Documentation Changes

TODO. (List every documentation needing an update here, starting by the New and Noteworthy documentation.)

Tests and Non-regression strategy

TODO. (This part of the document should describe the strategy to use to correctly test the evolution and guarantee the non-regression.)

Implementation choices and tradeoffs

TODO. (Any important tradeoff or choice made during the implementation should be referenced here with pros/cons leading to the final decision.)