Eclipse Community Forums: Graphiti » Complicated Shapes & Member Access

Home » Modeling » Graphiti » Complicated Shapes & Member Access

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 #1385116 is a reply to message #1385109]

Wed, 04 June 2014 08:43

Eclipse User

If you have six different types elements in your diagram and you created your own ecore model (so you have one object for each element), why do you extend ContainerShape?
You only need to differentiate between your objects or is there something else?

Re: Complicated Shapes & Member Access [message #1385140 is a reply to message #1385116]

Wed, 04 June 2014 10:22

Eclipse User

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 10:23] by Moderator

Re: Complicated Shapes & Member Access [message #1385153 is a reply to message #1385140]

Wed, 04 June 2014 11:59

Eclipse User

Maybe I don't get it, but it seems like you have only one model for all your elements in your diagram and thats why you have to search for attributes.
Your canLayout Method looks like that, because you just test for if the 'pe' is an instance of your 'MyShape'.
If you have an object for each of your elements, you can simply ask for the business object and you dont have to test for anything.

Re: Complicated Shapes & Member Access [message #1385408 is a reply to message #1385153]

Fri, 06 June 2014 04:53

Eclipse User

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 04:54] by Moderator

Re: Complicated Shapes & Member Access [message #1385585 is a reply to message #1385408]

Mon, 09 June 2014 14:08

Eclipse User

We use a similar approach: http://5ise.quanxinquanyi.de/2012/12/13/the-way-we-use-graphiti/

Re: Complicated Shapes & Member Access [message #1385822 is a reply to message #1385408]

Wed, 11 June 2014 08:17

Eclipse User

Simon,

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.

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.

Michael

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:08

We 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:17

Simon,
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

Previous Topic:	Getting Text from graphic element
Next Topic:	Selection Behavior problems

Goto Forum:

-=] Back to Top [=-

Current Time: Thu Jul 24 09:27:29 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter