| link from container and child shape to the same object? [message #713522] |
Mon, 08 August 2011 15:05  |
 Hernan Gonzalez
Messages: 188
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.
(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: (no subject) [message #713982 is a reply to message #713855] |
Tue, 09 August 2011 14:16  |
Hernan Gonzalez
Messages: 188
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 |
|
|
Powered by
FUDForum. Page generated in 0.04175 seconds
] 
Search
Help
Register
Login
Home
