Bug 547941 - Workspace image path attribute should be evaluated as an expression
Summary: Workspace image path attribute should be evaluated as an expression
Status: NEW
Alias: None
Product: Sirius
Classification: Modeling
Component: Diagram (show other bugs)
Version: unspecified   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2019-06-05 03:55 EDT by Felix Dorner CLA
Modified: 2019-06-12 08:29 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Dorner CLA 2019-06-05 03:55:27 EDT
Hi,

it often that the workspace image for a domain object depends on certain attributes of the object. This results in lots of 'conditional style' elements. It would be so much simpler if the workspace path value was an expression. As an example, I have an object that has an enum attribute. For each literal value of the enum, I have an image, <literal>.png. If the path was an expression, I could just do something like workspacePath=aql:'path_prefix' + self.enumAttrib + '.png' (not sure if that's really aql, but you get the point). Compare that to the N conditional style elements needed at the moment.
Comment 1 Felix Dorner CLA 2019-06-05 07:39:09 EDT
And another disadvantage of using multiple conditional styles that I need to copy/paste all the other properties, such as label size, alignment and whatever.
Comment 2 Laurent Fasani CLA 2019-06-07 12:15:49 EDT
Hello thank you for suggestion of enhancement.
Effectively, it would be interesting to have an expression to define the image path.
Nevertheless, I don't think this enhancement will be added in the roadmap soon particularly because you already have the ability to functionally achieve what you want eventhough effectively with more pain that you would like to.
Comment 3 Felix Dorner CLA 2019-06-12 08:29:08 EDT
BTW, there are other elements that point to images and these ARE already interpreted as an expression, e.g. DecorationDescription, so I'd guess it would be very easy to duplicate that behaviour.