Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 322994

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: CoreAssignee: 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    

Description Yann Tanguy CLA 2010-08-18 04:39:41 EDT
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.
Comment 1 Yann Tanguy CLA 2010-08-18 04:45:02 EDT
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 ?
Comment 2 Camille Letavernier CLA 2012-02-07 10:31:59 EST
The new property view allows editing the constraint specification, so this seems to be fixed ; unless this bug specifically targets the X-Text implementation.