Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » link from container and child shape to the same object?(A doubt about the tutorial)
link from container and child shape to the same object? [message #713522] Mon, 08 August 2011 15:05 Go to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 181
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
In the tutorial, "the container shape and likewise the shape containing the text label are related to a corresponding EClass". Here, the container shape corresponds to the business object (EClass in the example) and the child shape to an attribute of the same object. Two links are created, for the container and for the child.
http://help.eclipse.org/indigo/topic/org.eclipse.graphiti.doc/resources/docu/gfw/visio/pictogram-model.png

(BTW, shouldn't the legend on the right be "EClass" instead of "EPackage"?)

I'm not sure what difference makes the second link (line 'link(shape, addedClass);' in source code), I would have assumed that the fist link somewhat implied that children shapes are also linked to the same business object (perhaps I'm not understanding fully the implicancies of the "link").

Further, later, when the update feature is implemented, and we want to update the children shape (the label), the code seems to rely only on the container-shape link. Is this correct?

[Updated on: Mon, 08 August 2011 15:08]

Report message to a moderator

Re: link from container and child shape to the same object? [message #713851 is a reply to message #713522] Tue, 09 August 2011 07:43 Go to previous messageGo to next message
Matthias Gorning is currently offline Matthias GorningFriend
Messages: 81
Registered: April 2010
Location: Germany
Member
1. You are right, the legend on the right should be named "EClass" instead of "EPackage"

2. Yes, in this example the second link with "link(shape, addedClass)" is not necessary. But it makes life easier. E.g. if you write a direct editing feature for the label shape, you can simply access the business object. See class TutorialDirectEditEClassFeature (line 40ff) from the tutorial example.

3. Correct, in the update feature it wasn't necessary to use this additional link.

Best regards,
Matthias
(no subject) [message #713855 is a reply to message #713522] Tue, 09 August 2011 07:43 Go to previous messageGo to next message
Matthias Gorning is currently offline Matthias GorningFriend
Messages: 81
Registered: April 2010
Location: Germany
Member
1. You are right, the legend on the right should be named "EClass" instead of "EPackage"

2. Yes, in this example the second link with "link(shape, addedClass)" is not necessary. But it makes life easier. E.g. if you write a direct editing feature for the label shape, you can simply access the business object. See class TutorialDirectEditEClassFeature (line 40ff) from the tutorial example.

3. Correct, in the update feature it wasn't necessary to use this additional link.

Best regards,
Matthias
Re: (no subject) [message #713982 is a reply to message #713855] Tue, 09 August 2011 14:16 Go to previous message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 181
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
Thanks.
I'm trying to understand the 'link' concept, and to which extent it relates to the 'bind' concept as it's usually found in View-Model pattern.
Your answer points to one aspect: sort of a convenience pointer:
Quote:
2. Yes, in this example the second link with "link(shape, addedClass)" is not necessary. But it makes life easier. E.g. if you write a direct editing feature for the label shape, you can simply access the business object. See class TutorialDirectEditEClassFeature (line 40ff) from the tutorial example.


But this could also have been done by asking for the BO of the parent pictogram (container shape), right?

Further, I wonder how the link/binding works the other way: for example, when the tutorial implements the update: will the framework call this method (when the BO change) twice, for both links? If so, shouldn't the tutorial have implemented that with the more specific link instead?

Another thing that leaves me uncomfortable is the way in which the tutorial code navigates the pictogram tree: for example, that update code: to locate the label it loops over pictogram children, asking for types ('instanceof' operators) and relying on the precise structure (ordering) of the tree. This looks to me messy and very difficult to maintain, specially considering that the same assumptions are donde in several features and methods. Sure, a tutorial must sometimes sacrifice good practices for the sake of simplicity/brevity but I wonder if there are some samples or suggestions on how to navigate more complex graphs in a cleaner way.

[Updated on: Tue, 09 August 2011 14:25]

Report message to a moderator

Previous Topic:Anchors or nested shapes?
Next Topic:Load Diagram from File in RCP
Goto Forum:
  


Current Time: Tue Nov 25 20:52:22 GMT 2014

Powered by FUDForum. Page generated in 0.02057 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software