| Recursively nested containers possible? [message #1698042] |
Wed, 10 June 2015 14:55  |
 Moritz Eysholdt
Messages: 161
Registered: July 2009
Location: Kiel, Germany |
Senior Member |
|
|
Hi,
I would like to to build a sirius editor for an Ecore model with Statements. There are There is a ParalelStatement, an IfStatement and a FunctionCallStatement. The ParallelStatement contains a list of Statements for Thread1 and a list of statements for Thread2. The IfStatement contains a list of statements for the then-block and another list of statements for the else-block.
I imagine it to look like this:
I did manage to create a diagram with expected (nested) containers and nodes. However, this only seems to work with "Child Presentation" set to "Free Form". This isn't appropriate for me, since the statements should be displayed as a list/stack in their proper order. Users should be able to change the oder of the list, but they should not be able to freely more them around on the canvas.
However, "Child Presentation"
- "List" is not allowed for (indirectly) nested containers (according to the specification model validator)
- "Horizontal Stack" and "Vertical Stack" are not allowed when a child or parent also have "child representation" set to stack.
How would you approach this? Did I miss something?
I saw in the documentation that sirius can make use of custom GMF EditParts, but I'd really like to avoid implementing one of those.
thanks for an answer,
Moritz
[Updated on: Wed, 10 June 2015 14:56] Report message to a moderator |
|
|
| Re: Recursively nested containers possible? [message #1698050 is a reply to message #1698042] |
Wed, 10 June 2015 16:22  |
|
Le 10/06/2015 16:55, Moritz Eysholdt a écrit :
> Hi,
>
> I would like to to build a sirius editor for an Ecore model with Statements. There are There is a ParalelStatement, an IfStatement and a FunctionCallStatement. The ParallelStatement contains a list of Statements for Thread1 and a list of statements for Thread2. The IfStatement contains a list of statements for the then-block and another list of statements for the else-block.
>
> I imagine it to look like this:
>
> I did manage to create a diagram with expected (nested) containers and nodes. However, this only seems to work with "Child Presentation" set to "Free Form". This isn't appropriate for me, since the statements should be displayed as a list/stack in their proper order. Users should be able to change the oder of the list, but they should not be able to freely more them around on the canvas.
>
> However, "Child Presentation"
> - "List" is not allowed for (indirectly) nested containers (according to the specification model validator)
The rule is a "List" container mapping cannot contain/reuse another
container mapping
> - "Horizontal Stack" and "Vertical Stack" are not allowed when a child or parent also have "child representation" set to stack.
We currently chose to limit the supported strucure of compartiments to
one level, the layout would be ok with nested sub-compartments but the
resize of those constructs might not be properly handled for such strucures.
>
> How would you approach this? Did I miss something?
For the moment, I would use (for the provided screenshot) :
.. a FreeForm container mapping to represent ParallelStatement (and in a
future version allowing several level of compartiments: HorizontalStack)
.. a VerticalStack container mapping to represent Thread - a notion which
does not seem to exist in your ecore, so in your case two mappings with
ParralelStatement as domain class and var:self as candidates expression.
Those mappings children will have to call self.firstThreadStatements or
self.secondThreadStatements in their candidates expression.
.. a List container mapping to represent IfStatement and FunctionCalls (a
single mapping with an abstract domain class to control the order of
displayed elements: with two mappings they will be sorted by mapping and
then by semantic candidates expression result)
.. a Node mapping to represent terminal function calls.
But IMO, in your ecore, each reference "ownStatement" is typed by
Statement, so you would need a fully recursive structure be able to
support each possible combination ( another parallel blok in the first
if, several if levels, ...), but for the moment you can not use the
vertical/horizontal stacks for what you would like to achieve.
The first solution I proposed might only be acceptable if you for the
structure displayed in your screenshot with the proper order, and no
allowed user order modifications.
But with the current structure of your metamodel (references typed by
the abtract type Statement), I think you might for the moment use a
horizontal stack container mapping for the ParallelStatement with two
FreeForm container mapping for the "threads". Then you might provide you
own edit policies to forbid the move of the other kind of statements
(reorder might be done in wizards) and your own layout provider to
control the placement.
You might also introduce a Thread concept (with a statements list and a
list of threads in your ParallelStatement). This might allow you to
define simpler mappings and reuse them as much as possible to produce a
recursive structure of mappings abl to represent any Statement depth.
> I saw in the documentation that sirius can make use of custom GMF EditParts, but I'd really like to avoid implementing one of those.
>
> thanks for an answer,
> Moritz
>
Regards
--
Maxime - Obeo
Need professional services for Sirius?
http://www.obeodesigner.com/sirius
Maxime Porhel - Obeo
Need training or professional services for Sirius?
http://www.obeodesigner.com/sirius
|
|
|
Powered by
FUDForum. Page generated in 0.03074 seconds
] 
Search
Help
Register
Login
Home
