Complicated Shapes & Member Access [message #1385109] |
Wed, 04 June 2014 08:00  |
Eclipse User |
|
|
|
Hi,
with complicated (Container)Shapes accessing members is kinda a pain.
For example I have 6 types each of those has a Text with the name and a PolyLine as optional seperator below.
Always accessing these elements with getChildren().get(0) or via the Pattern (aka Property) mechanism strikes me as pretty unstable/unsafe (typecast/ tree-search heavy).
So I created my own ecore model that references graphiti.ecore and created my own base Shape.
MyShape extends ContainerShape
-> Text mainTitle
-> Polyline titleSeperator
(don't forget a MyPackage inst = MyPackage.eINSTANCE; during plugin startup)
I am quite happy with my solution, so I am curios why doing it like that isn't mentioned in the tutorial / or is that discouraged because ? .
[Updated on: Wed, 04 June 2014 08:03] by Moderator
|
|
|
|
|
|
|
|
|
Re: Complicated Shapes & Member Access [message #1386103 is a reply to message #1385822] |
Fri, 13 June 2014 08:36  |
Eclipse User |
|
|
|
Andreas Graf wrote on Mon, 09 June 2014 14:08We use a similar approach: http://5ise.quanxinquanyi.de/2012/12/13/the-way-we-use-graphiti/
Yes =)
Michael Wenz wrote on Wed, 11 June 2014 08:17Simon,
while this seems to be perfectly fine in your case, I'm not certain if that
is usable in general. As I understood you use those fields to display a kind
of header or title in your shapes, right? But there are for sure shapes that
do not have such a title area.
I made a simplified example, but still a majority of my complicated Shapes have some header, seperators, some different anchors and so on.
Michael Wenz wrote on Wed, 11 June 2014 08:17
If this is all about identifying your shapes again, Graphiti offers custom
properties that can be set fro each shape or graphics algorithm. Setting a
property for a kind of identifier could be used to find your shapes again
more reliably.
Besides that it might make sense for you to look into the IdPattern class
(part of o.e.g.pattern plugin). It introduces ids for the parts of a complex
shape that can be indiviually updated. Under the hood also a custom property
is used for that.
Yeah but using the properties mechanism moves compile time errors towards runtime.
Aka, typecasts, the strings to identify them and the "search" algorithm to find the right PropertyContainer is code that gets shifted around a lot (at least when I program).
Damn why is this so hard to express.. with Andreas approach Id and Type are bound and problems are immediately thrown at compile time.
Or a different example (that can't be done by properties), let's say some type of PE always has 3 linked objects, my code at many places now always has to go through the list and search for the proper type / or I just set a local attribute of my inherited PE once and always access that.
I was/am mostly worried that since it is not explicitly supported/mentioned I might run into problems in the future.
Of the top of my head, that somewhere down the line things like;
- xy instanceof ContainerShapeImpl (instead of ContainerShape) is used internally
- Rectangle is now not a interface anymore but a final class
*ok both somewhat odd things to do, but I am not much of an expert on this.
thank you,
Simon
[Updated on: Fri, 13 June 2014 08:37] by Moderator
|
|
|
Powered by
FUDForum. Page generated in 0.24038 seconds