| Summary: | [All Diagrams] Any kind of ValueSpecification should be allowed to use as a Constraint specification | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Yann Tanguy <yann.tanguy> |
| Component: | Core | Assignee: | Remi Schnekenburger <rschnekenburger> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | arnaud.cuccuru, cletavernier, klaas.gadeyne, sebastien.gerard |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 322933 | ||
Arnaud, can you provide some info regarding the way xtext editors are selected for a specific element ? Is it always based on the selection nature or is it more complex ? For instance how is the xtext MARTE VSL editor chosen ? Is it based in a fixed set of predefined conditions (element type, stereotype...) or is it possible to use a general Java matcher ? The new property view allows editing the constraint specification, so this seems to be fixed ; unless this bug specifically targets the X-Text implementation. |
Currently, a Constraint is created with a LiteralString as specification. First, if a default choice is a good thing to avoid the user create the ValueSpecification himself, an Opaque expression would probably be a better choice as an OpaqueExpression owns a "language" property which is nearly always useful. What remains important here is that the kind of language used for specification Constraint will depend on users, and it should be easy for any one to customize the Palette in order to add a creation tool for its own kind of constraint (for instance Java Constraint button, OCL constraint button). Then, as the UML2 metamodel allow to use any kind of ValueSpecification as Constraint specification, Papyrus should offer the possibility to replace the default value specification with an other one (or a new one). Papyrus should be able to show the constraint specification graphically as a string. The Constraint specification edition should be possible with enhanced editor (editors with completion..., xtext OCL editor...) either in the Property View or in diagram. Currently Papyrus supports xtext editor integration (for example to edit Property label), but I'm not sure this is sufficient here as the editor is not related to a specific kind of element but a specific pattern. In other words (lets consider the OCL example), what I need here is the OCL xtext editor to be selected when editing the specification of a Constraint which is an OpaqueExpression with "OCL" language, the selected element nature ("Constraint") is not sufficient to select the correct editor.