| Complicated Shapes & Member Access [message #1385109] |
Wed, 04 June 2014 12:00  |
 Simon Sperl
Messages: 21
Registered: May 2014 |
Junior Member |
|
|
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 12:03] Report message to a moderator |
|
|
|
| Re: Complicated Shapes & Member Access [message #1385140 is a reply to message #1385116] |
Wed, 04 June 2014 14:22  |
Simon Sperl
Messages: 21
Registered: May 2014 |
Junior Member |
|
|
I think with a bit examplified code I can show why;
How layoutFeature looks with my own ecore model
@Override
public boolean canLayout(ILayoutContext context) {
return context.getPictogramElement() instanceof MyShape;
}
@Override
public boolean layout(ILayoutContext context) {
MyShape mainShape = (MyShape) context.getPictogramElement();
...
mainShape.getTitleSeparator().setVisible(hasAttributes || hasMethods);
mainShape.getAttributeSeparator().setVisible(hasAttributes && hasMethods);
mainShape.getTitleText().setValue("Hello");
without patterns;
@Override
public boolean canLayout(ILayoutContext context) {
PictogramElement pe = context.getPictogramElement()
return pe instanceof ContainerShape
// && hasPropertyIsMyShape(pe)
&& getBusinessObjectForPictogramElement(pe) instanceof MyObject;
}
@Override
public boolean layout(ILayoutContext context) {
ContainerShape mainShape = (ContainerShape) context.getPictogramElement();
...
mainShape.getChildren().get(1).setVisible(hasAttributes || hasMethods);
int idx = searchForFirstPolylineAfterIndex(1); //ugh
mainShape.getChildren().get(idx).setVisible(hasAttributes && hasMethods);
mainShape.getChildren().get(0).setValue("Hello");
or using Patterns
@Override
protected boolean layout(IdLayoutContext context, String id) {
ContainerShape mainShape = (ContainerShape) context.getPictogramElement();
...
findById(mainShape, "titleSeparator").setVisible(hasAttributes || hasMethods);
findById(mainShape, "attributeSeparator").setVisible(hasAttributes && hasMethods);
((Text)findById(mainTitle, "mainTitle")).setValue("Hello");
aka by defining my own Shapes, I can safe a lot of searching/ifs & typecasting
[Updated on: Wed, 04 June 2014 14:23] Report message to a moderator |
|
|
|
| Re: Complicated Shapes & Member Access [message #1385408 is a reply to message #1385153] |
Fri, 06 June 2014 08:53 |
Simon Sperl
Messages: 21
Registered: May 2014 |
Junior Member |
|
|
No that is a minor advantage, the big advantage is that I (or the Pattern) doesn't have to search for my GraphicAlgorithms (/Shapes) in the GA/Shape-Tree.
During Adding I set my custom attributes to the elements in the tree that will get accessed all the time.
Saving myself potentially pretty complicated code to find those Shapes/GAs again and again in the tree later.
[Updated on: Fri, 06 June 2014 08:54] Report message to a moderator |
|
|
|
|
| Re: Complicated Shapes & Member Access [message #1386103 is a reply to message #1385822] |
Fri, 13 June 2014 12:36 |
Simon Sperl
Messages: 21
Registered: May 2014 |
Junior Member |
|
|
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 12:37] Report message to a moderator |
|
|
Powered by
FUDForum. Page generated in 0.03873 seconds
] 
Search
Help
Register
Login
Home
