| Trouble with Connection Content Parts (GEF4 0.4.0) [message #1760210] |
Mon, 24 April 2017 11:13  |
Eclipse User |
|
|
|
Hi,
in our project, we used GEF3 to realize an automaton editor. After migrating the entire tool to E4, we also migrated to GEF4 V. 0.2.0 as, back then, there was no 1.x release available yet.
Anyway, I am struggeling a bit with understanding the content parts for the connections. Does a connection always have to be the child of one of the nodes it is attached to?
Concretely, we have the following problem: When an editor is opened, the model is populated using the overridden getContentChildren() methods. Currently, all elements (nodes and connections) are children of the top layer (i.e. the automaton). Hence, the automaton's ContentBehavior adds all children - nodes and connections - at the same time by synchronizeContentChildren(...).
When a connection is activated during this step, its ContentBehavior calls the findOrCreatePartFor(...) method for the nodes. If this happens before the nodes existed, they are created and associated with the content (i.e. the model representation of the node) by contentPart.setContent(content);
The problem is here that this registration fails.
Lines 132-134 in AbstractContentPart:setContent(Object content) are:
//...
if (content != null && content != oldContent && getViewer() != null) {
registerAtContentPartMap(getViewer(), content);
}
//...
getViewer() returns null since the content's root depends on the anchorages or the parents which are both not set at this time yet. Ergo, the registration fails. The result is that findOrCreatePartFor(...) creates multiple parts for the same content, which is indeed undesired.
Should I override setContent() in AbstractContentPart or what would you suggest to tackle this issue?
Another, more general question: Is the EditPart hierarchiy, which has been mirrored from the model back in GEF3,(http://help.eclipse.org/mars/topic/org.eclipse.gef.doc.isv/guide/images/mvctree.gif) still present in GEF4's content parts or is there no longer explicit hierarchy in the parts themselves? It seems to me that anything works via getContentChildren now?
Thanks in advance for helping me out!
Best,
Florian
|
|
|
| Re: Trouble with Connection Content Parts (GEF4 0.4.0) [message #1760222 is a reply to message #1760210] |
Mon, 24 April 2017 14:02  |
| Eclipse User |
|
|
|
In contrast to GEF3, all ContentParts (also those controlling a Connection) have to refer to a parent (in GEF 3.x ConnectionParts only refer to a source and target).
Is is absolutely fine to have connections and nodes all contained directly in the content layer as you describe. Unfortunately, the content synchronization in GEF4 0.2.0 was not robust enough to handle all cases of such a scenario. We have revised it in GEF 5.0.0: it is now performed in two passes, so all children are synchronized before the anchorages are synchronized. Further, the behavior has been centralized to the root part, so there is not a ContentBehavior for each ContentPart any more.
To circumvent your problems, you could think of sorting the content children so the initialization is performed in an order that fits, or (and this probably is the better solution) to back-port the current ContentBehavior and trigger the synchronization in two passes.
Yes, the content parts still manifest a hierarchy, and yes, its controlled via the content children, which is very similar to the mechanism used in GEF 3.x. However, connections were handled differently in GEF 3.x. In GEF4 there is no dedicated controller type, but we instead employed a generic mechanism to anchor parts on others (anchorage-anchored).
|
|
|
| Re: Trouble with Connection Content Parts (GEF4 0.4.0) [message #1760290 is a reply to message #1760222] |
Tue, 25 April 2017 10:56 |
| Eclipse User |
|
|
|
|
Thanks for the quick response! I will have a look at the according GEF 5.0.0 code to find some inspiration or even adapt it as you said. The issue I described only arises on connections where source and target are identical (i.e. two node views are created before one of them is registered for the content). So maybe I can come up with some workaround for these special cases, for example by replacing the visual anchorage afterwards and disposing the obsolete node then. Although it is not nice, it should fix the issue and not consume too much performance.
|
|
|
Powered by
FUDForum. Page generated in 0.03407 seconds
Home