| child nodes for children of a referenced semantic object [message #175079] |
Mon, 03 March 2008 07:30  |
Eclipse User |
|
|
|
Originally posted by: mopr.xxxxx.org
Hello,
normally in GMF, the semantic objects of child nodes are contained in or at least referenced by the semantic object of the parent node. What if such a direct relation does not exist ?
My semantic model looks like this:
EClass A ------> EClass B <>------> EClass C
0..1 *
Intended graphical representation: There is a node for A (not top-level). The node for A has child nodes for C. B does not have a visual representation in the diagram.
I'm struggling with this problem for several days now and did not find any info in the tutorials or on the wiki. It would be great if someone could help!
Many thanks in advance,
Oliver
|
|
|
|
| Re: child nodes for children of a referenced semantic object [message #175362 is a reply to message #175292] |
Tue, 04 March 2008 08:46  |
| Eclipse User |
|
|
|
Originally posted by: mopr.xxxxx.org
Alex,
thanks for your answer! I had also considered this solution but did not want to change the domain model at first. However, in the meantime I found the thread from a month ago where you describe that the "GMF-level only" solution is quite intricate (valdiation and compilation errors, etc.).
So I've tried the EMF-level solution but ran into a problem: the derived transient, volatile, unchangeable EReference I have added to EClass A is non-containment, of course. Therefore I cannot define it as "Containment Feature" for the Child Reference in .gmfmap and only defining it as "Children Feature" causes a validation error.
Do I have to set the derived EReference in A to "containment" ? But, if I'm not mistaken, this would not be good style because the objects are also contained somewhere else ...
Thanks again,
Oliver
Alex Shatalin schrieb:
> Hello Oliver,
>
> The easiest way is to define derivede feature in EClass A and implement
> it to return all the indirectly referenced instances of EClass C
>
> -----------------
> Alex Shatalin
>
>
|
|
|
|
| Re: child nodes for children of a referenced semantic object [message #175622 is a reply to message #175517] |
Tue, 04 March 2008 15:46 |
| Eclipse User |
|
|
|
Originally posted by: mopr.xxxxx.org
Ok. I set "Containment Feature" to the new derived EReference in EClass A (with the text editor because the ERef is non-containment) and except a validation error in .gmfmap everything worked fine (no compile erros).
But there are two drawbacks:
- it seems that quite some code is generated which would cause problems if being executed (e.g. code for creating a new EClass C below EClass A) ; probably this code won't be used as long as I do not define a tool in .gmfmap, but it's a strange feeling to have this code around :-)
- also the notification code on EMF level is not trivial at all ; to implement it thoroughly, one would have to generate notifications when the link A-->B is set and when the list of Cs in B is changed ; it is quite some work to do the adapter management (to support the second case) and to find the Cs that have been added and/or removed (to support the first case).
BTW: Since there seems to be no standard solution to this problem yet, you might be interested in something I tried before posting on this newsgroup: Adding in .gmfmap a child node to the node of EClass A with "Domain Element", "Containment Feature" and "Children Feature" all undefined; and adding everything else in the code. All that needs to be done here is to change MyModelDiagramUpdater#getXYZSemanticChildren() and add a few updates in EditPart#handleNotificationEvent().
There were only two minor problems with this approach, but I get the impression that it would be easier to fix these than those of the EMF-level approach. And this would make for an extremely flexible solution. For example, it would be good to allow to define a domain model "Element" for a node in .gmfmap without defining a containment/children feature, so that the code can automatically decide what node to create for a child I return from MyModelDiagramUpdater#getXYZSemanticChildren().
Alex Shatalin schrieb:
> Hello Oliver,
>
> I see. You can try doing this by manually editing .gmfmap file for now..
> We'll update GMF editors in accordance once you prove this sulution works.
>
>
> -----------------
> Alex Shatalin
>
>
|
|
|
|
| Re: child nodes for children of a referenced semantic object [message #175696 is a reply to message #175653] |
Tue, 04 March 2008 17:57 |
| Eclipse User |
|
|
|
Originally posted by: mopr.xxxxx.org
So this leaves us with at least two approaches, both of which require minor fixes in GMF, if I'm not mistaken. Is something like that planned already? If not, do you think it makes sense to file a bug report?
Anyway, thanks again for your help so far!!
/Oliver
Alex Shatalin schrieb:
> Hello Oliver,
>
>> - it seems that quite some code is generated which would cause
>> problems if being executed (e.g. code for creating a new EClass C
>> below EClass A) ; probably this code won't be used as long as I do not
>> define a tool in .gmfmap, but it's a strange feeling to have this code
>> around :-)
> I suppose you should handle adding new Cs into this derived feature -
> then GMF-generated code should start working even on creating new C
> instances.
>
>> - also the notification code on EMF level is not trivial at all ; to
> That's true.
>
>> newsgroup: Adding in .gmfmap a child node to the node of EClass A with
>> "Domain Element", "Containment Feature" and "Children Feature" all
>> undefined; and adding everything else in the code. All that needs to
> You are right - this is another way to handle this situation.
>
> -----------------
> Alex Shatalin
>
>
|
|
|
|
| Re: child nodes for children of a referenced semantic object [message #175855 is a reply to message #175752] |
Wed, 05 March 2008 16:45 |
| Eclipse User |
|
|
|
Originally posted by: mopr.xxxxx.org
Alex,
I have now filed a bug to which I copy/pasted the info from our discussion.
https://bugs.eclipse.org/221542
Alex Shatalin schrieb:
> AFAIU, first approach (using derived property) is not working now due to
> the superfluous checks in the .gmfmap properties editor
Maybe it is a bit more difficult than just removing a validation rule.
The .gmfmap-editor would need to be changed to also offer non-containment references when setting "Containment Feature" AND the corresponding validation rule would need to be removed.
BUT: This would be a violation of the semantic of the "Containment Feature" property and would be confusing for users in the standard case.
> and what's wrong with second one (manual code modifications)?
See there bug report.
Cheers,
Oliver
|
|
|
Powered by
FUDForum. Page generated in 0.03475 seconds
] 
Search
Help
Register
Login
Home
