Home » Modeling » GMF (Graphical Modeling Framework) » "Element A" and "Element B" should contain both "Element C"
| "Element A" and "Element B" should contain both "Element C" [message #188929] |
Fri, 23 May 2008 04:42  |
Eclipse User |
|
|
|
Originally posted by: romantul.gmail.com
Hi,
I'm trying to implement a following thing with GMF:
|-----------| |-----------|
|Element A | |Element B |
|-----------| |-----------|
||---------||---->||---------||
||Element C|| ||Element C||
||---------|| ||---------||
|-----------| |-----------|
"Element A" and "Element B" should contain the same "Element C" as a
child Node.
In order to do it, the type of "Element A" and "Element B" aggregates
the type of "Element C", so I can define a compartment in the gmfgraph
and compartment mapping gmfmap and so on.
On the diagram I create the "Element A" and the "Element C" inside it.
Then I create "Element B" and set there "Element C" in the Properties view.
The Problem is - "Element C" disappears from out of "Element A".
How can I manage this Problem?
Thank you.
|
|
|
| Re: "Element A" and "Element B" should contain both "Element C" [message #188936 is a reply to message #188929] |
Fri, 23 May 2008 05:03  |
| Eclipse User |
|
|
|
Originally posted by: gmerin.integranova.com
Hi Tarantul,
That behaviour is normal. That is because an object can only have one
parent. So if you move Element C from A to B, then C is moved phisically
from A. Therefore, when A tries to refresh its Figure, it asks for his
semanticChildren and, as it does have none, then C is not drawn.
Since Ecore only has composite aggregations and no shared aggregations,
you'll have to simulate this behaviour. One way to achive this could be
creating a new Element X who stores a list of Elements C (with an
aggregation). Then, Elements A and B only need a simple Association with
Elements C.
I hope it helps!
Regards,
Gabriel.
tarantul escribió:
> Hi,
> I'm trying to implement a following thing with GMF:
> |-----------| |-----------|
> |Element A | |Element B |
> |-----------| |-----------|
> ||---------||---->||---------||
> ||Element C|| ||Element C||
> ||---------|| ||---------||
> |-----------| |-----------|
>
> "Element A" and "Element B" should contain the same "Element C" as a
> child Node.
>
> In order to do it, the type of "Element A" and "Element B" aggregates
> the type of "Element C", so I can define a compartment in the gmfgraph
> and compartment mapping gmfmap and so on.
>
> On the diagram I create the "Element A" and the "Element C" inside it.
> Then I create "Element B" and set there "Element C" in the Properties view.
>
> The Problem is - "Element C" disappears from out of "Element A".
>
> How can I manage this Problem?
> Thank you.
|
|
| |
| Re: "Element A" and "Element B" should contain both "Element C" [message #189040 is a reply to message #188936] |
Fri, 23 May 2008 07:01 |
| Eclipse User |
|
|
|
Originally posted by: romantul.gmail.com
Thank you Gabriel,
I understand this behavior, and I've already tried to make it this way
> One way to achive this could be
> creating a new Element X who stores a list of Elements C (with an
> aggregation). Then, Elements A and B only need a simple Association with
> Elements C.
"Element C" was then aggregated by the "Diagram" Element and associated
by "Element A" and "Element B".
The resulting problem is then - I can't define any compartments to draw
"C" inside of "A" or "B" as a child element.
This is because of the constrain for defining a compartment of some
element inside one another, there should be an aggregation between them.
Is there maybe another way to solve my problem?
Regards,
Roman
Gabriel Merin Cubero schrieb:
> Hi Tarantul,
> That behaviour is normal. That is because an object can only have one
> parent. So if you move Element C from A to B, then C is moved phisically
> from A. Therefore, when A tries to refresh its Figure, it asks for his
> semanticChildren and, as it does have none, then C is not drawn.
>
> Since Ecore only has composite aggregations and no shared aggregations,
> you'll have to simulate this behaviour. One way to achive this could be
> creating a new Element X who stores a list of Elements C (with an
> aggregation). Then, Elements A and B only need a simple Association with
> Elements C.
>
> I hope it helps!
> Regards,
> Gabriel.
>
> tarantul escribió:
>> Hi,
>> I'm trying to implement a following thing with GMF:
>> |-----------| |-----------|
>> |Element A | |Element B |
>> |-----------| |-----------|
>> ||---------||---->||---------||
>> ||Element C|| ||Element C||
>> ||---------|| ||---------||
>> |-----------| |-----------|
>>
>> "Element A" and "Element B" should contain the same "Element C" as a
>> child Node.
>>
>> In order to do it, the type of "Element A" and "Element B" aggregates
>> the type of "Element C", so I can define a compartment in the gmfgraph
>> and compartment mapping gmfmap and so on.
>>
>> On the diagram I create the "Element A" and the "Element C" inside
>> it. Then I create "Element B" and set there "Element C" in the
>> Properties view.
>>
>> The Problem is - "Element C" disappears from out of "Element A".
>>
>> How can I manage this Problem?
>> Thank you.
|
|
|
| Re: "Element A" and "Element B" should contain both "Element C" [message #189084 is a reply to message #189040] |
Fri, 23 May 2008 08:20 |
| Eclipse User |
|
|
|
Originally posted by: romantul.gmail.com
If I'm dowing it like this:
> > One way to achive this could be
> > creating a new Element X who stores a list of Elements C (with an
> > aggregation). Then, Elements A and B only need a simple
Association with
> > Elements C.
I get an error message while generating a Diagram Editor Gen Model (gmfgen):
"'Containment Feature' must be owned ba 'Domanin Meta Element' ... "
Is there another possibility to show nodes inside one another, without
defining a containment?
tarantul schrieb:
> Thank you Gabriel,
> I understand this behavior, and I've already tried to make it this way
>
> > One way to achive this could be
> > creating a new Element X who stores a list of Elements C (with an
> > aggregation). Then, Elements A and B only need a simple Association with
> > Elements C.
>
> "Element C" was then aggregated by the "Diagram" Element and associated
> by "Element A" and "Element B".
>
> The resulting problem is then - I can't define any compartments to draw
> "C" inside of "A" or "B" as a child element.
>
> This is because of the constrain for defining a compartment of some
> element inside one another, there should be an aggregation between them.
>
> Is there maybe another way to solve my problem?
>
> Regards,
> Roman
>
> Gabriel Merin Cubero schrieb:
>> Hi Tarantul,
>> That behaviour is normal. That is because an object can only have one
>> parent. So if you move Element C from A to B, then C is moved
>> phisically from A. Therefore, when A tries to refresh its Figure, it
>> asks for his semanticChildren and, as it does have none, then C is not
>> drawn.
>>
>> Since Ecore only has composite aggregations and no shared
>> aggregations, you'll have to simulate this behaviour. One way to
>> achive this could be creating a new Element X who stores a list of
>> Elements C (with an aggregation). Then, Elements A and B only need a
>> simple Association with Elements C.
>>
>> I hope it helps!
>> Regards,
>> Gabriel.
>>
>> tarantul escribió:
>>> Hi,
>>> I'm trying to implement a following thing with GMF:
>>> |-----------| |-----------|
>>> |Element A | |Element B |
>>> |-----------| |-----------|
>>> ||---------||---->||---------||
>>> ||Element C|| ||Element C||
>>> ||---------|| ||---------||
>>> |-----------| |-----------|
>>>
>>> "Element A" and "Element B" should contain the same "Element C" as a
>>> child Node.
>>>
>>> In order to do it, the type of "Element A" and "Element B" aggregates
>>> the type of "Element C", so I can define a compartment in the
>>> gmfgraph and compartment mapping gmfmap and so on.
>>>
>>> On the diagram I create the "Element A" and the "Element C" inside
>>> it. Then I create "Element B" and set there "Element C" in the
>>> Properties view.
>>>
>>> The Problem is - "Element C" disappears from out of "Element A".
>>>
>>> How can I manage this Problem?
>>> Thank you.
|
|
| |
| Re: "Element A" and "Element B" should contain both "Element C" [message #189351 is a reply to message #189084] |
Tue, 27 May 2008 05:53 |
| Eclipse User |
|
|
|
Originally posted by: gmerin.integranova.com
Hi again,
Unfortunately, the only way to achieve your goal is by handcoding your
behaviour. As you say, a compartment can only show child elements, not
associated elements (by default). But it's not imposible because, for
example, we've done exactly what you are trying to do when showing
referenced columns within a View Table in a DB Diagram.
However, for associations with other elements, I would suggest a custom
property tab instead of compartments because GMF considers compartments
as child containers and if you want to avoid this behaviour you'll have
to change the generated code.
tarantul escribió:
> If I'm dowing it like this:
>
> > > One way to achive this could be
> > > creating a new Element X who stores a list of Elements C (with an
> > > aggregation). Then, Elements A and B only need a simple
> Association with
> > > Elements C.
>
> I get an error message while generating a Diagram Editor Gen Model
> (gmfgen):
>
> "'Containment Feature' must be owned ba 'Domanin Meta Element' ... "
>
> Is there another possibility to show nodes inside one another, without
> defining a containment?
>
>
>
> tarantul schrieb:
>> Thank you Gabriel,
>> I understand this behavior, and I've already tried to make it this way
>>
>> > One way to achive this could be
>> > creating a new Element X who stores a list of Elements C (with an
>> > aggregation). Then, Elements A and B only need a simple Association
>> with
>> > Elements C.
>>
>> "Element C" was then aggregated by the "Diagram" Element and
>> associated by "Element A" and "Element B".
>>
>> The resulting problem is then - I can't define any compartments to
>> draw "C" inside of "A" or "B" as a child element.
>>
>> This is because of the constrain for defining a compartment of some
>> element inside one another, there should be an aggregation between them.
>>
>> Is there maybe another way to solve my problem?
>>
>> Regards,
>> Roman
>>
>> Gabriel Merin Cubero schrieb:
>>> Hi Tarantul,
>>> That behaviour is normal. That is because an object can only have one
>>> parent. So if you move Element C from A to B, then C is moved
>>> phisically from A. Therefore, when A tries to refresh its Figure, it
>>> asks for his semanticChildren and, as it does have none, then C is
>>> not drawn.
>>>
>>> Since Ecore only has composite aggregations and no shared
>>> aggregations, you'll have to simulate this behaviour. One way to
>>> achive this could be creating a new Element X who stores a list of
>>> Elements C (with an aggregation). Then, Elements A and B only need a
>>> simple Association with Elements C.
>>>
>>> I hope it helps!
>>> Regards,
>>> Gabriel.
>>>
>>> tarantul escribió:
>>>> Hi,
>>>> I'm trying to implement a following thing with GMF:
>>>> |-----------| |-----------|
>>>> |Element A | |Element B |
>>>> |-----------| |-----------|
>>>> ||---------||---->||---------||
>>>> ||Element C|| ||Element C||
>>>> ||---------|| ||---------||
>>>> |-----------| |-----------|
>>>>
>>>> "Element A" and "Element B" should contain the same "Element C" as a
>>>> child Node.
>>>>
>>>> In order to do it, the type of "Element A" and "Element B"
>>>> aggregates the type of "Element C", so I can define a compartment in
>>>> the gmfgraph and compartment mapping gmfmap and so on.
>>>>
>>>> On the diagram I create the "Element A" and the "Element C" inside
>>>> it. Then I create "Element B" and set there "Element C" in the
>>>> Properties view.
>>>>
>>>> The Problem is - "Element C" disappears from out of "Element A".
>>>>
>>>> How can I manage this Problem?
>>>> Thank you.
|
|
|
| Re: "Element A" and "Element B" should contain both "Element C" [message #190987 is a reply to message #189351] |
Wed, 04 June 2008 09:03 |
| Eclipse User |
|
|
|
Originally posted by: romantul.gmail.com
Gabriel, thank you for this answer. Now I at least know, what is
definitely NOT functioning :-) .
> ... . But it's not imposible because, for
> example, we've done exactly what you are trying to do when showing
> referenced columns within a View Table in a DB Diagram.
I would prefer the solution above. Can you please describe this way more
detailed. For example, what DB Diagram do You mean? Or is there
somewhere a functioning example with this kind of functionality?
Regards,
Roman
Gabriel Merin Cubero schrieb:
> Hi again,
> Unfortunately, the only way to achieve your goal is by handcoding your
> behaviour. As you say, a compartment can only show child elements, not
> associated elements (by default). But it's not imposible because, for
> example, we've done exactly what you are trying to do when showing
> referenced columns within a View Table in a DB Diagram.
>
> However, for associations with other elements, I would suggest a custom
> property tab instead of compartments because GMF considers compartments
> as child containers and if you want to avoid this behaviour you'll have
> to change the generated code.
>
> tarantul escribió:
>> If I'm dowing it like this:
>>
>> > > One way to achive this could be
>> > > creating a new Element X who stores a list of Elements C (with an
>> > > aggregation). Then, Elements A and B only need a simple
>> Association with
>> > > Elements C.
>>
>> I get an error message while generating a Diagram Editor Gen Model
>> (gmfgen):
>>
>> "'Containment Feature' must be owned ba 'Domanin Meta Element' ... "
>>
>> Is there another possibility to show nodes inside one another, without
>> defining a containment?
>>
>>
>>
>> tarantul schrieb:
>>> Thank you Gabriel,
>>> I understand this behavior, and I've already tried to make it this way
>>>
>>> > One way to achive this could be
>>> > creating a new Element X who stores a list of Elements C (with an
>>> > aggregation). Then, Elements A and B only need a simple
>>> Association with
>>> > Elements C.
>>>
>>> "Element C" was then aggregated by the "Diagram" Element and
>>> associated by "Element A" and "Element B".
>>>
>>> The resulting problem is then - I can't define any compartments to
>>> draw "C" inside of "A" or "B" as a child element.
>>>
>>> This is because of the constrain for defining a compartment of some
>>> element inside one another, there should be an aggregation between them.
>>>
>>> Is there maybe another way to solve my problem?
>>>
>>> Regards,
>>> Roman
>>>
>>> Gabriel Merin Cubero schrieb:
>>>> Hi Tarantul,
>>>> That behaviour is normal. That is because an object can only have
>>>> one parent. So if you move Element C from A to B, then C is moved
>>>> phisically from A. Therefore, when A tries to refresh its Figure,
>>>> it asks for his semanticChildren and, as it does have none, then C
>>>> is not drawn.
>>>>
>>>> Since Ecore only has composite aggregations and no shared
>>>> aggregations, you'll have to simulate this behaviour. One way to
>>>> achive this could be creating a new Element X who stores a list of
>>>> Elements C (with an aggregation). Then, Elements A and B only need a
>>>> simple Association with Elements C.
>>>>
>>>> I hope it helps!
>>>> Regards,
>>>> Gabriel.
>>>>
>>>> tarantul escribió:
>>>>> Hi,
>>>>> I'm trying to implement a following thing with GMF:
>>>>> |-----------| |-----------|
>>>>> |Element A | |Element B |
>>>>> |-----------| |-----------|
>>>>> ||---------||---->||---------||
>>>>> ||Element C|| ||Element C||
>>>>> ||---------|| ||---------||
>>>>> |-----------| |-----------|
>>>>>
>>>>> "Element A" and "Element B" should contain the same "Element C" as
>>>>> a child Node.
>>>>>
>>>>> In order to do it, the type of "Element A" and "Element B"
>>>>> aggregates the type of "Element C", so I can define a compartment
>>>>> in the gmfgraph and compartment mapping gmfmap and so on.
>>>>>
>>>>> On the diagram I create the "Element A" and the "Element C" inside
>>>>> it. Then I create "Element B" and set there "Element C" in the
>>>>> Properties view.
>>>>>
>>>>> The Problem is - "Element C" disappears from out of "Element A".
>>>>>
>>>>> How can I manage this Problem?
>>>>> Thank you.
|
|
|
Goto Forum:
Current Time: Fri Nov 07 04:02:27 EST 2025
Powered by FUDForum. Page generated in 0.05898 seconds |
Home