Bug 486163

Summary:

Validation of interpreted expression at the level of the color palette might fail because of missing Services

Product:

[Modeling] Sirius

Reporter:

Cedric Brun <cedric.brun>

Component:

Core

Assignee:

Project inbox <sirius.core-inbox>

Status:

NEW ---

QA Contact:

Severity:

normal

Priority:

CC:

laurent.redor, pierre-charles.david

Version:

3.1.0

Keywords:

triaged

Target Milestone:

---

Hardware:

OS:

Linux

Whiteboard:

Bug Depends on:

Bug Blocks:

485136

Attachments:

Description	Flags
my.project.design Project	none

Description Cedric Brun

2016-01-20 05:44:11 EST

Steps to reproduce

1- Create a Palette in a VSM with an interpolated color
2- make sure the "Color Value Computation Expression" uses a Java service which is declared in one of the Viewpoints
3- right click-> validate

The editor will complain about the missing service despite the fact that it is declared and imported.

I assume the same bug exists for any color definition which uses interpreted expressions.

Comment 1 Laurent Redor

2016-01-26 05:28:37 EST

Created attachment 259379 [details]
my.project.design  Project

my.project.design.zip: You can also import this project and launch the validation on "MyPalette" of "/my.project.design/description/project.odesign"

Comment 2 Pierre-Charles David

2016-11-23 16:13:28 EST

The root issue is that expression completion/validation is by default tied to the concept of dialect, see DialectManagerImpl.createInterpretedExpressionQuery(EObject, EStructuralFeature). But color palettes and their content are not part of a specific dialect, so we end up using the DefaultInterpretedExpressionQuery, which does not handle them either.

We could make DefaultInterpretedExpressionQuery smarter to know about them, or use the IInterpretedExpressionQueryProvider introduced for properties views (which are not technically a dialect either).

Wherever we put the code, it will be relatively tricky, because it will need to identify (through the cross-referencer) all the "call-sites" where the color is used, and then infer which variables and services are available on all of them. Maybe some kind of recursive call on createInterpretedExpressionQuery on each call site, and an "IntersectionInterpretedExpressionQuery" returning only the results common to all call sites would do the trick.